Kubernetes、コンテナ技術を活用した開発アジリティー向上にインフラアーキテクトはどう貢献したのか：コンテナベースのCI/CD本番事例大解剖（1）（2/3 ページ）

Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートの事例を基に解説する連載。初回は、インフラアーキテクトの視点から技術選定の考え方について解説。

[藤原涼馬，リクルートテクノロジーズ]

Dockerコンテナ化の目的

　前述の要件3「中期的視点での運用コストを削減する」という観点から重要となるのが、開発メンバーが安心して機能の追加、コードのリファクタリングを実施できる状況を確立することです。そのためには、開発メンバーがテストを充実させること、信頼できるテスト結果を開発メンバーに逐次提供できるようにすることが重要になります。

　そこで、サービスを構成する各コンポーネントのDockerコンテナ化の目的を明確にする際には、前述のThe Twelve Factorsのうち、主に下記2点を考慮することにしました。

• 依存関係
• 廃棄容易性

CI/CD基盤におけるDocker活用のメリット

　そもそもDockerでは、コンテナイメージを活用することで、動作しているバイナリと、そのバイナリに関係した各種ライブラリが意図した構成かつテスト済みであることを確認しやすくなります（図2）。

図2　Dockerのメリット

“依存関係”により実現すること

　The Twelve Factorsにおける“依存関係”とは、バイナリのビルド、実行に必要なライブラリなどの導入を明示的に宣言し分離することを表します。

　最初から暗黙的に種々のライブラリがインストールされていることを前提とせず、コードとして明示することで、バイナリの実行に必要な最小限のライブラリだけを導入します（実際には、全てを手動で記述することなく、言語固有の管理システムを使うことが多い）。

　Dockerでは、Dockerfileでバイナリをビルドするための環境定義と手順、バイナリそのものの動作環境定義を明示することで、信頼のおけるビルドの実現に取り組むことにしました。

“廃棄容易性”により実現すること

　The Twelve Factorsにおける“廃棄容易性”とは、高速な起動とグレースフルなシャットダウンを表しますが、ここでは「高速な起動」を主に考慮することにしました。これによって、ビルド後（またはビルド中）にテストを実行することで、短時間でCIを実行することを目的にしました。

　また、ここで述べている廃棄容易性とは意味合いが少しずれますが、「意図して残そうとしない限り、コンテナ削除後にコンテナ内のファイルが残らない」という特性も考慮しました。これにより、ビルドとテストの完了後に、残存している中間生成物やバイナリが次回のビルド、テスト時の適正な動作を妨げてしまうような事態を予防することが容易になります。

　廃棄容易性を考慮することで、開発メンバーが自身の書いたコードについて各種判断（コード品質、処理仕様の準拠、各種設定が適切に反映されていることなど）のよりどころとなる信頼性の高いテストを実現しようとしました。

「高信頼なビルド、テストの実現」を目的に

　この2つの特性を考慮して、コンテナイメージのビルドとテストを自動で実行してくれる、信頼性の高いCIパイプラインを提供することをDockerコンテナ化の主目的としました。

Kubernetes対応の目的

　Dockerコンテナ化の場合と同様に「何を意図してKubernetes対応を行うのか」を明確にする必要があります。

　The Twelve Factorsのうち、Kubernetesは、Dockerが提供する2つの要素（前述の依存関係、廃棄容易性）以外の大部分の実現を助けてくれます（もちろん、それぞれの要素をどの程度助けてくれるかは濃淡がありますが）。今回の事例では、Kubernetesがカバーしてくれる要素のうち、下記2点を主に考慮することにしました。

• 開発／本番一致
• 設定

CI/CD基盤におけるKubernetes活用のメリット

　そもそもKubernetesを活用することのメリットとして特に強調しておきたいのが下記の2点です（図3）。

1. アプリケーションの非機能面（特に可用性、性能）の設計、実装の負担を削減できる
2. サービスを構成するコンテナ間の関係性をYAMLファイル（リソースマニフェスト）の形で宣言的に記述できる

図3　Kubernetesのメリット

　またKubernetesは、AWS、Microsoft Azure、GCP（Google Cloud Platform）などメジャーなパブリッククラウドでマネージドサービスが提供されているだけではなく、オンプレミスでも利用可能であり、特定のクラウド環境でなければ動作しないといったことがない点も特筆すべきポイントです。前述の要件2「特定のクラウドベンダーへのロックインを、できる限り回避する」を充足できます。

“開発／本番一致”で実現すること

　The Twelve Factorsにおける“開発／本番一致”とはCDを容易にするために開発環境と本番環境のギャップを小さくすることを表します。

　Kubernetesのリソースマニフェストとサービスディスカバリを利用して開発環境、本番環境などの環境に関係なく、可能な限り同様の構成を実現します。これによって環境を問わず同一のリソースマニフェストファイル、手順を用いてアプリケーションをデプロイできるようにします。

　開発環境と本番環境で同一の手順でデプロイできるようにすることで（図4）、デプロイのプロセスも開発環境で磨き込むことを目指しました。

図4　マニフェストファイルによる開発／本番一致とデプロイ手順の統一

“設定”で実現すること

　最後に解説するのは、The Twelve Factorsの“設定”（設定を環境変数に格納すること）です。

　どうしても開発／本番一致が実現できない部分（DBのパスワードといった各種認証情報、外部連携先のIPアドレスやFQDNなど）をKubernetesのConfigMapやSecretリソースを利用して設定できるようにします（もちろんアプリケーション開発者には、ここで設定した情報を読み込むようにしてもらいます）。

　これらの環境依存部分についてもマニフェストファイルとしてコード化して管理することで、「環境ごとに、どこまでが同じで、どこからが異なるか」といった差分をコードで管理することが可能になります（図5）。

図5　ConfigMapやSecretリソースによる環境差分の明示

「非機能要件を充足するための設計／実装コストの低減」「デプロイ品質の磨き込み」を目的に

　Kubernetes対応の目的をまとめると、「非機能要件を充足するための設計／実装コストの低減」「デプロイ品質の磨き込み」となりました。

　ここまで、Docker、Kubernetesを活用すると判断した根拠について解説してきました。しかしユーザーが使うWebサービスを開発、運用するには、もちろん、それらの周辺を支える仕組みについても選定と設計、実装を進める必要があります。ここからは、CI/CD、監視／モニタリングにおけるツール選定について解説します。