CLOUD NATIVE TRAIL MAPを読み解く！

LinuCエヴァンジェリストの鯨井貴博@opensourcetechです。


はじめに
今回は、CNCFが考える クラウド ネイティブへの移行を開始する企業向けの概要 である CLOUD NATIVE TRAIL MAP を読み解いてみます！



CLOUD NATIVE TRAIL MAPとは
クラウド ネイティブへの移行を開始する企業向けの概要 であり、
オープン ソースのクラウド ネイティブ テクノロジーを活用するための推奨プロセス です。

ステップは10あり、ステップ3以降はオプションとなります。
各ステップで利用できるサービスやツール・ソフトウェアは、クラウド ネイティブ ランドスケープで紹介されており、好きなものを選択して利用することができます。



なぜ、読み解こうと思ったのか
個人的に遡ってみると、2018年頃から kubernetes を意識し始めました。
www.opensourcetech.tokyo
www.opensourcetech.tokyo

また、2022年3月20日にCKA(Certified Kubernetes Administrator)を取得しました。


そして、2022年12月よりkubernetesの研修販売を開始したのですが、
改めてkubernetesが含まれる CLOUD NATIVE TRAIL MAPを読み解き、
Cloud Nativeを俯瞰的に捉えてみたいと思ったからです。



Cloud Nativeとは
ではまず、Cloud Nativeとは何ぞやというところから。



WHAT IS CLOUD NATIVE?
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Com-bined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this para-digm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

クラウドネイティブとは?
クラウド ネイティブ テクノロジにより、組織は、パブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの最新の動的な環境でスケーラブルなアプリケーションを構築および実行できます。 コンテナー、サービス メッシュ、マイクロサービス、不変のインフラストラクチャ、および宣言型 API は、このアプローチの例です。 これらの手法により、回復力があり、管理しやすく、監視可能な疎結合システムが可能になります。 堅牢な自動化と組み合わせることで、エンジニアは影響の大きい変更を頻繁かつ予測可能な形で最小限の労力で行うことができます。 Cloud Native Computing Foundation は、オープン ソースのベンダー中立プロジェクトのエコシステムを育成および維持することにより、このパラダイムの採用を推進しようとしています。 最先端のパターンを民主化し、これらのイノベーションをすべての人が利用できるようにします。

要約すると
最新テクノロジーを駆使して 影響を最小限にした上で 短いサイクルでリリースを頻繁に行い、自動復旧や容易な管理などを実現していこうという考え方、そんなところでしょうか。



Step1 CONTAINERIZATION(コンテナ化)


1. CONTAINERIZATION
• Commonly done with Docker containers • Any size application and dependencies (even PDP-11 code running on an emulator) can be containerized
• Over time, you should aspire towards splitting suitable applications and writing future functionality as microservices

1. コンテナ化
• Docker コンテナで一般的に行われる
• 任意のサイズのアプリケーションと依存関係 (エミュレーターで実行されている PDP-11 コードも含む) をコンテナー化できます。
• 時間の経過とともに、適切なアプリケーションを分割し、将来の機能をマイクロサービスとして作成することを目指す必要があります。

これまで物理筐体や仮想マシン(VM)にOSをインストールしてサービスを構築していたものを、コンテナにしようというものです。
軽量(数十～数百メガバイト程度)・起動の速さ(数秒)などコンテナの特徴を活用する、そんな捉え方でいいかと思います。



Step2 CI/CD(Continuous Integration/Continuous Delivery)(継続的インテグレーション/継続的デリバリー)


2. CI/CD
• Setup Continuous Integration/Continuous Delivery (CI/CD) so that changes to your source code automatically result in a new container being built, tested, and deployed to staging and eventually, perhaps, to production
• Setup automated rollouts, roll backs and testing
• Argo is a set of Kubernetes-native tools for deploying and running jobs, applications, workflows, and events using GitOps paradigms such as continuous and progressive delivery and MLops

2. CI/CD
• 継続的インテグレーション/継続的デリバリー (CI/CD) をセットアップして、ソース コードを変更すると、新しいコンテナーが自動的にビルド、テストされ、ステージングにデプロイされ、最終的には本番環境にデプロイされるようにします。
• 自動化されたロールアウト、ロールバック、およびテストのセットアップ
• Argo は、継続的および漸進的な配信や MLops などの GitOps パラダイムを使用して、ジョブ、アプリケーション、ワークフロー、およびイベントを展開および実行するための一連の Kubernetes ネイティブ ツールです。

コンパイルやテストなどを行う "CI" と、デプロイ(リリース)を行う "CD" であり、
以下の中から選択できます。


詳細は、こちら



Step3 ORCHESTRATION & APPLICATION DEFINITION(オーケストレーションとアプリケーションの定義)


3. ORCHESTRATION & APPLICATION DEFINITION
• Kubernetes is the market-leading orchestration solution
• You should select a Certified Kubernetes Distribution, Hosted Platform, or Installer: cncf.io/ck
• Helm Charts help you define, install, and upgrade even the most complex Kubernetes application

3. オーケストレーションとアプリケーションの定義
• Kubernetes は市場をリードするオーケストレーション ソリューションです
• 認定された Kubernetes ディストリビューション、ホステッド プラットフォーム、またはインストーラーを選択する必要があります: cncf.io/ck
• Helm チャートは、最も複雑な Kubernetes アプリケーションの定義、インストール、アップグレードにも役立ちます

高機能なコンテナ環境を提供するkubernetes(様々なディストリビューションやクラウドサービス)、アプリケーションの定義をしてくれるHelmなどから選択します。


詳細は、こちら


詳細は、こちら



Step4 OBSERVABILITY & ANALYSIS(可観測性と分析)


4. OBSERVABILITY & ANALYSIS
• Pick solutions for monitoring, logging and tracing • Consider CNCF projects Prometheus for monitoring, Fluentd for logging and Jaeger for Tracing
• For tracing, look for an OpenTracing-compatible implementation like Jaeger

4. 可観測性と分析
• モニタリング、ロギング、トレースのソリューションを選択する
• モニタリング用の CNCF プロジェクト Prometheus、ロギング用の Fluentd、トレース用の Jaeger を検討してください。
• トレースについては、Jaeger などの OpenTracing 互換の実装を探します。

以下の機能を使って、サービスの状況を観測/分析すること
モニタリング：収集したデータをグラフなどで可視化する機能
ロギング：ログ収集に関する機能
トレース：コンテナ(マイクロサービス)間のやり取りを追跡する機能

詳細は、こちら


詳細は、logging
詳細は、tracing
詳細は、chaos-engineering





Step5 SERVICE PROXY, DISCOVERY, & MESH(サービス プロキシ、検出、およびメッシュ)


5. SERVICE PROXY, DISCOVERY, & MESH
• CoreDNS is a fast and flexible tool that is useful for service discovery
• Envoy and Linkerd each enable service mesh architectures
• They offer health checking, routing, and load balancing

5. サービス プロキシ、検出、およびメッシュ
• CoreDNS は、サービス検出に役立つ高速で柔軟なツールです。
• Envoy と Linkerd はそれぞれサービス メッシュ アーキテクチャを有効にします
• ヘルスチェック、ルーティング、負荷分散を提供

サービスの検出をするためのデータエントリー(名前解決や構成データベースなど)、
アプリケーションの公開(サービスプロキシ)・アプリケーション間の通信制御(サービスメッシュ)に関する機能ですね。


詳細は、こちら


詳細は、こちら


詳細は、こちら



Step6 NETWORKING, POLICY,& SECURITY(ネットワーク、ポリシー、およびセキュリティ)


6. NETWORKING, POLICY,& SECURITY
To enable more flexible networking, use a CNI-compliant network project like Calico, Flannel, or Weave Net. Open Policy Agent (OPA) is a general-purpose policy engine with uses ranging from authorization and admission control to data filtering. Falco is an anomaly detection engine for cloud native.

6. ネットワーク、ポリシー、およびセキュリティ
より柔軟なネットワーキングを有効にするには、Calico、Flannel、または Weave Net などの CNI 準拠のネットワーク プロジェクトを使用します。 オープン ポリシー エージェント (OPA) は、承認やアドミッション コントロールからデータ フィルタリングまで、さまざまな用途に使用される汎用ポリシー エンジンです。 Falco は、クラウド ネイティブの異常検出エンジンです。

アプリケーション(コンテナ)間で使われるスイッチング・ルーティング・FW(L4/L7)を利用するネットワーク機能や、
認証・承認・監査(アドミッションコントロール)を行うもの。

詳細は、こちら


詳細は、こちら



Step7 DISTRIBUTED DATABASE & STORAGE(分散データベースとストレージ)

7. DISTRIBUTED DATABASE & STORAGE
When you need more resiliency and scalability than you can get from a single database, Vitess is a good option for running MySQL at scale through sharding.Rook is a storage orchestrator that integrates a diverse set of storage solutions into Kubernetes.Serving as the "brain" of Kubernetes, etcd provides a reliable way to store data across a cluster of machines.TiKV is a high performant distributed transactional key-value store written in Rust.

7. 分散データベースとストレージ
単一のデータベースから得られる以上の回復力とスケーラビリティが必要な場合、Vitess は、シャーディングを通じて MySQL を大規模に実行するための優れたオプションです。Rook は、さまざまなストレージ ソリューションのセットを Kubernetes に統合するストレージ オーケストレーターです。 Kubernetes の "etcd は、マシンのクラスター全体にデータを保存するための信頼できる方法を提供します。TiKV は、Rust で記述された高パフォーマンスの分散トランザクション キー値ストアです。

SQLやNoSQLのデータベース、キーバリューストア、kubernetesの構成情報を管理するetcdなどです。


詳細は、こちら


詳細は、こちら


詳細は、こちら



Step8 STREAMING & MESSAGING(ストリーミングとメッセージ)

8. STREAMING & MESSAGING
When you need higher performance than JSON-REST, consider using gRPC or NATS. gRPC is a universal RPC framework. NATS is a multi-modal messaging system that includes request/reply, pub/sub and load balanced queues. CloudEvents is a specification for describing event data in common ways.

8.ストリーミングとメッセージ
JSON-REST よりも高いパフォーマンスが必要な場合は、gRPC または NATS の使用を検討してください。 gRPC はユニバーサル RPC フレームワークです。 NATS は、要求/応答、pub/sub、および負荷分散キューを含むマルチモーダル メッセージング システムです。 CloudEvents は、一般的な方法でイベント データを記述するための仕様です。

イベント(何かが起こった)を伝える仕組み(メッセージング)やその情報連携(ストリーミング)に関するもの。


詳細は、こちら


詳細は、こちら



Step9 CONTAINER REGISTRY & RUNTIME(コンテナ レジストリとランタイム)

9. CONTAINER REGISTRY & RUNTIME
Harbor is a registry that stores, signs, and scans content. You can use alternative container runtimes. The most common, both of which are OCI-compliant, are containerd and CRI-O.

9. コンテナ レジストリとランタイム
Harbor は、コンテンツを保存、署名、およびスキャンするレジストリです。 代替コンテナ ランタイムを使用できます。 どちらも OCI に準拠している最も一般的なものは、containerd と CRI-O です。

コンテナイメージを置くレポジトリやクリーンなイメージの管理や、
kubernetes/Dockerなどのコンテナユーザーツールとコンテナレポジトリ・コンテナが通信する仕様(ランタイム)です。


詳細は、こちら


詳細は、こちら



Step10 SOFTWARE DISTRIBUTION(ソフトウェア配布)

10. SOFTWARE DISTRIBUTION
If you need to do secure software distribution, evaluate Notary, an implementation of The Update Framework.

10. ソフトウェア配布
安全なソフトウェア配布を行う必要がある場合は、更新フレームワークの実装である Notary を評価してください。

コンテナイメージが改ざんされていないこと、その場合はNotaryなどを使うとよい。


詳細は、こちら



CLOUD NATIVE TRAIL MAPを読み解いた感想
これまではオンプレに構築したkubernetesやマネージドサービスで、コンテナ(Deployments,Pods)デプロイ/アップグレード・サービス公開(Service)など操作してきたのですが、
CLOUD NATIVE TRAIL MAPにおいては "Step1 コンテナ化 + オプション(Step3~10の中からちょっとだけ使う程度)" に該当する部分であることが分かりました。

また、Step2のCI/CDをやってみる・オプション(Step3-10)のそれぞれのサービス・ツール・プロジェクトについて知り、使ってみる必要があることも分かったので深堀してみようと思います。

landscapeも以前はたくさんあるなぁという程度でそっと閉じていましたが、
これからは向き合うことができそうですw