コンテナは場所を選ばない!「オンプレ or クラウド×コンテナ」(後編)

はじめに

前回は、業界で一番使われているクラウドサービス「AWS」のコンテナ活用について紹介しました。今回は、Microsoft社が提供するクラウドサービス「Azure」とGoogle社が提供するクラウドサービス「GCP」のコンテナ活用について説明します。

Azureとは

Azureは現在、50を超える国と地域に展開するデータセンターと強力なWANネットワークを持ち、この設備をクラウドプラットフォームとしてユーザーへ提供しています。日本国内でも東日本、西日本と2拠点を有し、多くのユーザーが利用しています。

Azureが提供するプラットフォームには「IaaS」と「PaaS」の2種類のサービスがあります。「SaaSは?」と思う方も多いでしょうが、Microsoft社のSaaSと言えば「Microsoft 365(旧称 Office 365)」が有名ですね。Azureとの連携が必須となっていますが、Azureサービスとは別のサービスです(図1)。

図1：Azureサービス提供範囲

Azureのコンテナサービス

Microsoft社と言えば、多くの方がWindowsをイメージするでしょう。コンテナサービスはWindowsというよりLinux系OSでよく使用されるイメージがありますが、AzureのコンテナサービスはMicrosoft社が提供するだけあって、Windows OSにも対応しています。また、現状のAzureコンテナサービスの多さからMicrosoft社もコンテナサービスに力を入れていることがうかがえます。

図2に示すように、AzureにはKubernetes Service、Container Instanceなどのコンテナサービスがありますが、以降ではPaaSのサービスであるWeb App for Containersについて説明していきます。

図2：Azure Containers

Web App for Containers

Web App for Containersは、Web Appの実行イメージとしてDockerイメージをそのまま使えるというサービスです。ここで、Web App for Containersを説明する前にWeb Appについて軽く触れておきます。

Web Appは、正式には「App Service」と呼ばれ、Azure Portal上でも「App Service」と表記されています。App Serviceはインフラ部分にAzureフルマネージドのプラットフォームを使用しています。そのため、プラットフォーム上にJava、Node.js、PHP、Python、Rubyなどのプログラミング言語で簡単にWebアプリを構築できます。

Web App for Containersでは、開発者はDocker形式のアプリケーションの実行環境を含めた独自のコンテナイメージを持ち込むことで簡単にコンテナサービスを利用できます。これにより、コンテナの特徴である環境間のスムーズな移行の恩恵を受けられますし、コンテナサービスの初心者でも簡単なDockerファイルの作成方法さえわかっていれば、すぐに利用することができます(図3)。

図3：Azure App Service＆Web App for Containers

また、Web Appの機能として提供されているスケールアップやオートスケールアウト、デプロイメントスロット(Blue/Green Deployment)など、本来ならば一から設計・設定する必要がある機能もWeb Appの機能の一部として提供されているため、Web App for Containersを使用する優位性は高いと言えます。OSの修正プログラム適用といった各種機能もWeb App内で実施してくれるので、運用管理面でもだいぶ楽になります。

レジストリサービス－ACR

コンテナレジストリと言えばDocker Hubですが、AWSにはElastic Container Registry(ECR)があるように、AzureにもAzure Container Registry(ACR)というコンテナレジストリがあります。Azureを利用する際は、Azureコンテナサービスとの連携機能が豊富であることから、ACRを選択すると便利です。

ACRやDocker Hubのパブリック／プライベートレジストリ経由で、Docker Hubの公式イメージやローカル／クラウド上のDocker開発環境で準備したカスタムイメージを簡単にデプロイできます。ただ、Azureにはサブスクリプションと呼ばれる課金請求の枠組みがあり、その枠によってはACRのプライベートエンドポイントが利用できないなどの制約があるため、セキュリティ面からACRを使用できない場合もあります。要件に合わせて、どのレジストリサービスが良いかを検討しましょう。

Google Cloud Platformとは

Google Cloud Platform(GCP)のコンテナサービスを説明する前に、軽くGCPの歴史を紹介します。

GCPは2008年に登場したGoogle App Engine(GAE)という、Googleのインフラを利用してアプリケーションを実行できるサービスから始まります。その後ストレージサービスのGoogle Cloud Storage(GCS)やRDBサービスのGoogle Cloud SQLが、2012年にはデータ分析基盤であるBigQueryが発表されました。

そして、2013年にはコンピュートサービスであるGoogle Compute Engine(GCE)が登場し、同年にこれまでのGoogleのクラウドサービスを統一、それに合わせて名称もGoogle Cloud Platform(GCP)に変更され、晴れて世に出たというわけです。

その後にも様々なサービスがGCPに追加されていくのですが、2014年にはGoogleが開発したコンテナオーケストレーションツール「Borg」を前身にオープンソース化したKubernetesを基盤とするコンテナサービスのGoogle Container Engineが発表されました。その後2017年にGoogle Container Engineは名称変更され、Google Kubernetes Engine(GKE)になるのです(図4)。

図4：GCPのかんたんな歴史

GCPのコンテナサービス

パブリッククラウドの大きな強みは多くのマネージドサービスが存在することですが、GCPにおけるコンテナ関連のマネージドサービスをいくつかピックアップして紹介します。それぞれに役割や特徴があり、組み合わせて利用することもできます(図5)。

図5：GCP コンテナ関連サービス

・レジストリサービス－Google Container Registry(GCR)

GCRはGoogle Cloud上で実行されるプライベートなコンテナイメージレジストリです。GCPにおけるGCRへのアクセス制御はCloud IAM(IAM)を使用します。

Cloud IAMは「誰が、どのリソースに対して、どの様な操作が可能か」を定義するGCPのサービスで、これによりコンテナイメージへのアクセス権限や表示権限、ダウンロード権限などの制御が可能となり、より柔軟でセキュアな管理が実現できます。

また、Container Analysisというサービスを有効化することで、コンテナイメージをGCRにPushした際に自動でイメージに脆弱性スキャンを実行し、脆弱性の内容や重大度情報を表示できます。さらに、Container Analysisはスキャンしたコンテナイメージのメタデータを継続的に監視しており、Push時にはなかったパッケージの脆弱性が新たに発覚した場合は、スキャン済みのコンテナイメージを再度分析するという機能も備えています。

・コントロールプレーンサービス－Google Kubernetes Engine(GKE)

GKEはGCPにおけるKuberntesのマネージドサービスです。GKEではKubernetesの環境構築に面倒な作業が不要で、コマンド1つでKubernetesクラスタを作成できます。そして、マスタの管理や更新は全てGoogleが実施してくれるため、開発者の負担をグッと軽減できます。

また、GKEのクラスタ管理機能にはノードに関する自動機能が備えられています。これらにより、一部分ですがノード管理の手間を省くことができます。

・ノードの自動アップグレード－Auto Upgrade
ノードの自動アップグレードを有効にすることで、マスタが更新された際にクラスタ内のノードも自動でバージョンアップしてくれるようになります(※マスタの更新は最新バージョンが安定版になったタイミングです)。

また、セキュリティのアップデートも常に最新バージョンが適用されるため、セキュリティの観点でもメリットがあります。ノードのバージョンアップはノード数が多ければ多いほど面倒になるため、自動的に行われるのは非常に嬉しい機能です(図6)。

図6：Auto Upgrade

・ノードの自動修復－Auto Healing
GKEは常にノードのヘルスチェックを行っており、ステータスが一定時間の間に連続して失敗したノードがあった場合、自動で対象のノードを再作成します。

・ノードの自動スケール－Auto Scale
GKEではクラスタ内のリソース需要に応じて、自動的にノードプール(クラスタ内で同じ構成を持つノードのグループ)にノードを追加します。事前にノードプールの最小サイズと最大サイズを設定すれば、手動でノードの追加／削除する手間を省くことができます。

また、GKEはCloud MonitoringやCloud Loggingと統合されており、クラスタを作成するとKubernetes専用のモニタリングダッシュボードが提供されるようになります。CPU使用率、メモリ使用量などの指標や収集された各種ログが表示されるため、クラスタの状況をより深く把握できるようになります。

さらに、KubernetesのPod内にあるコンテナで不明なコードや信頼できないコードが実行された際に、ノードのホストカーネルを保護するGKE Sandboxという機能があります。GKE SandboxはgVisorというOSSのコンテナランタイムにより実現していますが、gVisorはアプリケーションとホストカーネルの間に入ることで、ホストカーネルの代わりにアプリケーションからのシステムコールを処理します。

これにより、システムコールの脆弱性を悪用した攻撃などからホストや同じホストにデプロイされているコンテナを保護できるのです。

まだまだ紹介したいサービスは多々ありますが、最後にBinary Authorizationというサービスを紹介します。

Binary Authorizationは信頼できるコンテナイメージだけをGKEにデプロイすることを保証するセキュリティ管理サービスです。Binary Authorizationではプロジェクトあるいはクラスタレベルでポリシーを定めることができ、例えばコンテナイメージの脆弱性スキャンツールによる署名や管理者が生成した署名の有無などを検証することでGKEへのコンテナデプロイを制御できます。

GKEでは様々なサービスと連携することでクラスタ管理を容易にし、豊富なセキュリティ対策によりクラスタやアプリケーションを保護できるようになっているのです(図7)。

図7：GKEとの連携サービス例

コンテナ採用に向けた検討プロセス

最後に、システムにコンテナを導入するために必要な検討事項を紹介します。

多くのオンプレミスのシステムは、ハードウェアの保守サイクルに合わせてシステム更改が発生します。担当者にとってシステム更改は新しい技術の採用やサービスの拡充を図る大きなチャンスです。ぜひ最新の技術であるコンテナの採用を検討してみてください。また、ここで紹介する検討プロセスは、システムのクラウド化、仮想化基盤の導入などさまざまなことに流用できます。

既存システムに新しい基盤技術を導入する際は、大きく3つの観点で順番に評価します(図8)。

図8：検討ポイント

図8で示した要素は、いずれも新しい技術の導入において必ずクリアしなくてはならないポイントです。上長への説明・稟議を通すためにも、これらのポイントは明確に説明できるようにしておきましょう。

おわりに

今回は、Microsoft社が提供するクラウドサービス「Azure」、そして、Google社が提供するクラウドサービス「GCP」のコンテナサービスを紹介しました。前回の「AWS」を含め、クラウドサービスのトップリーダである各社の注目ポイントが少し見えてきたのではないでしょうか。

次回は、コンテナのメリットをさらに有効活用できるアーキテクチャ「マイクロサービス」について見ていきます。お楽しみに！