クラウドネイティブ活動の指針として、CNCFのCloud Native Trail Mapをどう考えるか：草間一人×青山真也 クラウドネイティブ対談（2）（1/2 ページ）
本連載では、2019年7月の「Cloud Native Days Tokyo 2019」でCo-chairを務めた青山真也氏と草間一人氏に、クラウドネイティブに関してじっくり語ってもらった対談の内容を、4回に分けて掲載している。前回の「クラウドネイティブは、どう誤解されているか」に続き、今回は第2回として、「CNCFのCloud Native Trail Mapを、クラウドネイティブ活動の指針としてどう考えるか」をテーマとした部分をお届けする。
本連載では、2019年7月の「Cloud Native Days Tokyo 2019」でCo-chairを務めた青山真也氏と草間一人氏に、クラウドネイティブに関してじっくり語ってもらった対談の内容を、4回に分けて掲載している。前回の「クラウドネイティブは、どう誤解されているか」に続き、今回は第2回として、「CNCFのCloud Native Trail Mapを、クラウドネイティブ活動の指針としてどう考えるか」をテーマとした部分をお届けする。
Cloud Native Trail Mapのアプローチはいいが……
――クラウドネイティブを目指すと決めた人たちが次に考えるのは、「ツール、製品、技術として何を採用するか」ということだと思います。これを考えるための材料として、Cloud Native Computing Foundation（CNCF）の「Cloud Native Trail Map」（下図）を取り上げたいと思います。CNCFは事実上、Kubernetesをベースとしたクラウドネイティブ技術を推進している組織ですので、そのエコシステムを積み上げて表現している側面がありますが、ここに示されているツールをこの順序に従って採用していくということについて、どう考えますか？
Cloud Native Trail Map中核部分の日本語訳
1.コンテナ化
一般的にはDockerコンテナで実行
あらゆるサイズおよび依存関係（エミュレーターで動作するPDP-11コード含む）のアプリケーションをコンテナ化可能
徐々に、分割に適したアプリケーションについては分割を実行し、将来の機能はマイクロサービスとして書くことを目指すべき
2. CI/CD
ソースコードへの変更が、自動的な新しいコンテナのビルド、テスト、そしてステージング環境および最終的には本番環境へのデプロイにつながるよう、継続的インテグレーション／継続的デリバリー（CI / CD）を構築する
-自動的なロールアウト、ロールバック、テストを構築する
3. オーケストレーション＆アプリケーション定義
-Kubernetesは市場をリードするオーケストレーションソリューション
-認定Kubernetesディストリビューション／ホステッドプラットフォーム／インストーラーを選択すべき
https://cncf.io/ck
-Helm Chartsは非常に複雑なKubernetesアプリケーションでも定義、インストール、アップグレードを助ける
4. 可観測性と分析
-モニタリング、ロギング、トレーシングのソリューションを選択する
-モニタリングではPrometheus、ロギングではFluentd、トレーシングではJaegerといったCNCFプロジェクトを検討する
-トレーシングではJaegerなど、OpenTracingに準拠した実装に着目する
5. サービスプロキシ、ディスカバリ＆メッシュ
-CoreDNSはサービスディスカバリに役立つ高速で柔軟なツール
-EnvoyとLinkerdはいずれもサービスメッシュアーキテクチャを実現
-ヘルスチェック、ルーティング、負荷分散を提供
6. ネットワーク＆ポリシー
より柔軟なネットワーキングを実現するには、Calico、Flannel、Weave NetのようなCNI準拠のネットワークプロジェクトを選択する。Open Policy Agent（OPA）は汎用ポリシーエンジンで、認可、リクエスト制御からデータフィルタリングまでの用途に使える。
7. 分散データベース／分散ストレージ
単一データベース以上の回復力や拡張性が必要な場合には、シャーディングを通じてMySQLを大規模に稼働できるVitessが良い選択肢になり得る。
Rookは多様なストレージソリューションをKubernetesに統合できるストレージオーケストレーターとして使える。
etcdはKubernetesの「頭脳」として機能し、マシンクラスタ全体に高い信頼性でデータを保存できる。
TiKVはRust言語で書かれた、高い性能を持つ分散トランザクションキーバリューストア。
8. ストリーミング＆メッセージング
JSON-RESTよりも高い性能が必要なら、gRPCあるいはNATSの利用を検討する。gRPCは広く使われているRPCフレームワーク。NATSはrequest/reply、pub/sub、負荷分散キューなどに対応するマルチモーダルなメッセージングシステム。
9. コンテナレジストリ＆ランタイム
Harborはコンテンツを保存し、署名し、スキャンするためのレジストリ。
コンテナランタイムは選択可能。containerdとCRI-Oは最もよく使われており、どちらもOCIに準拠している。
10. ソフトウェアディストリビューション
セキュアなソフトウェアディストリビューションを実施したいなら、The Update Frameworkの実装の一つであるNotaryを評価すると良い。
草間 Cloud Native Trail Mapのアプローチ自体は、とてもいいと思っています。「何か1つの技術やツールを入れたらクラウドネイティブ」ではなく、「自分たちに合ったものを着実にやっていく」ということがTrail Mapとして表現されています。この可視化の仕組み自体はとても好きです。ただ、後半は苦しい部分がありますね。
青山 順番も苦しいですね。
「CI/CDがクラウドネイティブの出発点になるべきでは？」「そもそも内製が先」
――ではその2つについてお聞きします。まず順番から行きますか？
青山 最初に「CI/CD」が来た方がいいのではないかと思います。「CI/CD」が整備されて、その次に「コンテナ化」があるべきだと思います。
草間 そうですね。
青山 「クラウドを使っている人が、いきなりコンテナ化をするか」という点に疑問があります。「CI/CDがちゃんと組まれていて、アプリケーションをこれに基づいてビルドして、使えるようになっている人たちが、コンテナ化していく」というほうがきれいかなと思います。
草間 私の（一般企業の開発体制構築支援という）仕事に関連して、順番に関して言うと、「CI/CD」の前に「テストを書け」ということが出てきます。テストを書くということは、まず「内製している」ということなんですよね。「まずはそこから」と考えると、「ステップ0」として「内製」が必要かと思います。青山さんのいる業界ではあり得ないとは思いますが、日本の一般企業に関してはまず内製化が必要です。そこがないので、「今動いているシステムあるいはパッケージを、どうクラウドに乗せるか」という話になりがちです。しかも、それを外注するという話になる。そこで、特に日本では0番が欲しいです。
青山 順番に関しては、後は「オーケストレーション＆アプリケーション定義」が3番、「可観測性と分析」が4番は良いとして、あとは5番ですかね。
草間 4番の「可観測性と分析」と5番の「サービスプロキシ、ディスカバリ＆メッシュ」のどちらを先にするか、順番が難しいよね。
青山 個人的には4番が先でいいと思います。でも「ストリーミング＆メッセージング」が8番は、無理がありますよね。
草間 だから言っているじゃない、後半苦しいって（笑）。
――草間さんが後半苦しいとおっしゃっているのはどういう点ですか？
草間 例えば6番は「ネットワーク＆ポリシー」で「CNI」と書いてありますが、これは3番の「オーケストレーション＆アプリケーション定義」の中身の話ですよね。6番の存在がよく分からないです。9番の「コンテナレジストリ＆ランタイム」も、3番のオーケストレーションの中で使われるもので、Harborについてもレジストリはその横にあるものです。
青山 そういうところありますね。5番の「サービスプロキシ、ディスカバリ＆メッシュ」まではいいのですが、6番の「ネットワーク＆ポリシー」くらいからは、項目を分けて前の段階に移して欲しいです。「レジストリ」はもっと前の段階に入るべきだし、「ソフトウェアディストリビューション」ももうちょっと前かな。前っていうか……。
Copyright © ITmedia, Inc. All Rights Reserved.