「Cloud Native Trail Map」の10ステップを紐解く(ステップ8～10)

はじめに

国内外で「クラウドネイティブ」に取り組む企業やエンジニアが増え、クラウドネイティブ関連のイベントへの参加者も活況を呈しています。一方で「クラウドネイティブとは、なんでしょうか?」という疑問を持っている方々も多くいます。

そこで本連載では、クラウドネイティブについて解説するとともに、それを支える基本的なテクノロジーやソフトウェア、そして、特にエンジニア視点として、どのように学んでいくかを紹介していきます。

今回は前回に引き続き、クラウドネイティブを実現するための道しるべとなる「Cloud Native Trail Map」について、ステップ8～10までを解説します。

Cloud Native Trail Mapの
10のステップ

Cloud Native Trail Mapには全部で10ステップありますが、ステップ3以降はすべてオプションで、状況に応じて選択されています。従って、クラウドネイティブになるには10個すべてのステップを達成することではないことに注意してください。

ステップ8:ストリーミングとメッセージング

JSON-RESTよりも高いパフォーマンスが必要な場合は「gRPC」や「NATS」の使用を検討します。

gRPC

gRPCは、RPCを実現するためにGoogleが開発したプロトコルの1つです。

RPCは、Remote Procedure Callの略で、「遠隔手続き呼び出し」とも呼ばれます。ヒューレット・パッカードに買収されたアポロコンピュータやサン・マイクロシステムズによってUNIX上に実装され、30年ほど前に流行したクライアント・サーバーモデルで利用が拡大しました。

RPCを利用すると、リモートにあるシステムでも、手元からコマンドを入力して処理を実行できます。機種や言語が異なっていても、問題なく通信できるようになっていることが特徴です。gRPCはマイクロサービスアーキテクチャーに最適で高速なRPCとして実装されています。 デフォルトではトランスポートにHTTP/2を利用し、構造化データをシリアル化するためには、Googleが開発したProtocol Buffersを利用することが一般的です。 複数のプログラミング言語をサポートしています。

●gRPC公式サイト：https://grpc.io/

NATS

NATSは、リクエスト／リプライ、パブ／サブ、ロードバランスキューなどのマルチモーダルなメッセージングシステムです。パフォーマンス、スケーラビリティ、および使いやすさを念頭において、開発されました。

以前は、サーバーレスに特化したイベントメタデータを記述するための標準が存在せず、サーバーレステクノロジーを提供するさまざまなベンダー独自でイベントに対応するなど、十分な相互運用性がありませんでした。そこで、クラウドにおけるイベント通知の標準仕様として定義されたのが「CloudEvents」です。サーバーレスやイベント駆動型のアーキテクチャを開発、実行、運用するためのより優れたツールをコミュニティが構築するための安定した基盤となっています。

●NATS公式サイト：https://nats.io/

●CloudEvents公式サイト：https://cloudevents.io/

ステップ9:コンテナレジストリとランタイム

コンテナレジストリを構築、あるいは利用して安全なコンテナイメージを利用できるようにします。

Harbor

「Harbor」は、コンテナイメージの保存、署名、脆弱性のスキャンを行うコンテナレジストリと呼ばれる機能を実装したソフトウェアです。元々、VMwareが社内で利用するために開発され、その後オープンソース化されました。

コンテナレジストリは、コンテナイメージの脆弱性を定期的に自動チェックするため、常に信頼性の高いコンテナイメージを安全に利用できます。

コンテナレジストリには、パブリッククラウド上にあるサービスではDocker Hub、 Google Container Registry、Amazon Elastic Container Registry、Azure Container Registryなどがあります。同様の機能を提供するOSSがHarborです。Harborは公開されているコンテナレジストリを利用できない企業や、あるいはマルチクラウド戦略を実施したい企業にとって1つの選択肢となるソリューションです。

●Harbor公式サイト：https://goharbor.io/

また、コンテナを実行するランタイムには複数のものがあるため、検討のうえ複数のコンテナランタイム候補から利用できます。最も一般的なものは「containerd」と「CRI-O」で、どちらもOCIに準拠しています。

コンテナでは当初「Docker」に大きな注目が集まりました。一方で、詳細の仕様について曖昧なところがあることから、開発者の間で混乱が起こっていました。そこで、コンテナのフォーマットとランタイムの標準化を図るためOpen Container Project(現在のOpen Container Initiative)が発足し、The Linux Foundationも立ち上げを支援しました。

そこで、定義された仕様が、下記の2つです。

• コンテナランタイムに関する仕様(Open Container Initiative Runtime Specification)
• コンテナイメージフォーマットに関する仕様(Open Container Initiative Image Format Specification)

Docker社はDockerのコンテナ管理機能を分離してCNCF(Cloud Native Computing Foundation)に寄贈し、CNCFは、そのコードをまとめて2018年にcontainerdとして公開しました。

●containerd公式サイト：https://containerd.io/

●CRI-O公式サイト：https://cri-o.io/

ステップ10:ソフトウェアの配布

ソフトウェアを安全に配布する必要がある場合は「The Update Framework(TUF)」を実装したソリューションを利用します。TUFはソフトウェアをアップデートする際のセキュリティを確保するためのフレームワークです。The Update Framework(TUF)の1つに「Notary」があります。TUFにより開発者はソフトウェアアップデートシステムのセキュリティを維持し、リポジトリや署名キーを侵害する攻撃者からも保護できます。

おわりに

今回まで、4回にわたってクラウドネイティブを実現するための道しるべとなる「Cloud Native Trail Map」について、そのステップを紹介しました。コンテナ化からオーケストレーション、サービスメッシュといったクラウドネイティブらしいステップから、セキュリティ、運用、性能管理といった今までのエンタープライズ向けIT基盤で注意しないといけない領域でのクラウドネイティブとしての対応まで、幅広くステップがあることをお分かりいただけたかと思います。

ただし、繰り返しになりますが、クラウドネイティブになるには10個すべてのステップを達成することではないことに注意してください。また、紹介した多くのオープンソース以外にも、各ステップで利用可能なオープンソースも開発され、発展中のものあります。それらに気がついたときにはCloud Native Trail Mapを振り返り、「どのステップに入るのだろうか」と考えてみるのも良いかも知れません。

次回は、2021年年初に発表された、CNCFのCTO/COOであるChris Aniszczyk氏が発表したクラウドネイティブに関する今後の予測を紹介します。