Kubernetesを選んだ技術的理由とコンテナをプロジェクトで活用する上でのポイント：先行事例に学ぶKubernetes企業活用の現実（終）（2/2 ページ）

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

Kubernetes、コンテナ活用上のポイント

　開発プロセス、運用プロセス関係なく、考えておくべき事柄について説明します。

• 前提条件
• CI/CDへの配慮
• ログの集約
• 監視・モニタリング

前提条件

　ここでは、Kubernetes（というよりはむしろコンテナ仮想化技術）をうまく活用する上での前提条件を記載します。条件を満たさなくても、Kubernetesの利用は可能かもしれませんが、さまざまな面で苦しくなるかもしれません。これまで筆者が取り組んできた経験から必要となりそうなものは下記4点です。

1. ソースコードリポジトリ（できればGit）
2. （プライベート）Dockerレジストリ
3. CIサーバ
4. 十分な帯域を持つネットワーク

　「ソースコードを管理するためのソースコートリポジトリ」「ビルドしたDockerイメージを格納するためのDockerレジストリ」、さらに「ソースコードからアプリケーションをビルドし、Dockerイメージ化した上で頻繁にテストを実行するためのCIサーバ」が必要となるでしょう。最後の「十分な帯域を持つネットワーク」は、「3.CIサーバ」において、基本的にネットワーク経由での情報のやりとりが多くなるためです。

CI/CDへの配慮

　一般的な開発環境では、CIサーバ上でテストを実施し、通過したコードのみをマージして次の段階へとステージングするといった流れになっていると思います。そこで問題となってくるのが、CIサーバ上でのテストにかかる時間です。ここを短縮することが開発エンジニアの士気に大きく関わります。

　コンテナを使うことでホストの状態をあまり意識しなくてよくなることを利用して、積極的にCIを回すようにすることで開発エンジニアがコードを改善するリズムを作り出すことができます。

　またGitHubやGitLabなどを利用して開発している場合は、プルリクエストが作成されたり、プルリクエスト中のブランチにコミットされたりした際に、テストを実行し、その結果をプルリクエストに含めるようにすることで、既存の仕様に対して破壊的な変更が加えられていないことをレビューできます。

　ある程度の規模のテストまでであれば、開発者のローカル端末上でのテストの実施が可能ですが、一定規模以上のサービスの開発時やレビューの観点から、CIサーバ上でのテストはどうしても必要になってきます。

　「コードリポジトリをどうするか」といった点も配慮が必要です。

　単一リポジトリでは「どのコンポーネントが変更されたのか」といったことを把握するのが困難になるためにテストにかかる時間は長くなってしまいがちです（全てのコンポーネントのテストが動作するため）。一方で、複数リポジトリではリポジトリの管理コストが高くなったり、開発メンバーがコーディングする上での操作が煩雑になったりするなどの事象が発生します。

　CIサーバ上でのテストにかかる時間を短縮し、エンジニアがフィードバックを受けるための時間を短縮することで機能実装、品質改善のスピードを上げることができます。

　CDについては、CDそのものというより、内容としては「デプロイ品質」の話になります。

　基本的には、「開発環境でデプロイを行うのと全く同じ方法でデプロイを実施できるようにする」のが最善です。ここでは人間の負担（主に精神的なもの）を少しでも減らすために、開発と本番で全く同じ方法でデプロイできるようにします。

　また、各種設定などについても環境間で可能な限り異ならないようにします。もしどうしても異なる場合は、クラウド環境が提供する各種機能や、Kubernetes自身の仕組み（ConfigMapやSecrets）を用いてカバーするようにしてください。極力、人間がその場で行う判断や操作（コピペを含む）を排除することを目指しましょう。

　開発環境では、特に開発の山場になると、1日に何度もデプロイがあるため、このような仕組みを作っておき負担を少しでも軽減することが開発効率の向上につながります。さらに、繰り返しデプロイを行う中で問題を洗い出し、適切に対処することでデプロイフローの品質が磨かれ、本番環境においても確実なデプロイを実現できるようになります。

　ここで述べたような品質の高いCI/CDを開発環境で実現することは、本番環境における安定したデプロイまでも実現します。

ログの集約

　Kubernetesを含むコンテナ仮想化基盤ではコンテナの起動と停止、削除が頻繁に行われます。また、コンテナが起動するノードについてもある程度制御は可能ですが、完全に固定することは、ノード自体の追加・削除が頻繁に行われることからも、あまり推奨されません。完全に固定した結果、ログをノード上だけに残すことは、仮想マシンベースである場合以上に、トラブルシューティングを困難にしてしまいます。

　そこで、ELK（Elasticsearch＋Logstash＋Kibana）スタック、EFK（Elasticsearch＋Fluentd＋Kibana）スタックなどに代表される、ログ集約・分析基盤を整備することが必要になります。

監視・モニタリング

　監視・モニタリングについても、仮想マシンベースと同様にOS（Dockerホスト）レイヤーのリソースやネットワークレイヤーの監視・モニタリングが必要です。これに加えて、頻繁に生成・停止・削除が行われるコンテナの監視・モニタリングが必要となります。

　この辺りについてはCNCFのcloudnativelandscapeなどを参考にしてソリューションを選択するようにしましょう。

　筆者の周辺では、自前でモニタリングを行う場合は「Prometeus」、SaaSサービスでは「Datadog」がよく聞かれます。

　どんなサービスを用いるかは、組織としてのモニタリング環境の運用に費やすことのできる人的リソースなどを考慮した上で選定を行うといいでしょう。

Kubernetesを活用することで得られるもの

　ここまで挙げたように、Kubernetesを導入する際には単純にアプリケーションをKubernetesに乗せるだけでは十分な成果を上げることはできません。開発プロセスなどについても大きな変更が必要になる場合があります。

　しかし、Kubernetes導入の際にポイントとなる部分は、Kuberenetesのみで必要となるものではなく、DevOpsの実現や、SoE（Systems of Engagement）といった世界観を実現する上で配慮されるべき仕組みの一部となっています。そこで、KubernetesをDevOpsやSoEにおける中心に据えるハブとして考えてみると「開発および運用プロセス全体としてどうあるべきか」が見えてくるように思えます。

Kubernetes活用の今後に向けて

　ここまでKubernetesの素晴らしさについて説明してきましたが、幾つか課題は残っています。特に、大量のyamlファイルの記述が必要なことは、Javaにおける「XML地獄」問題を思い起こさせます。

　しかしながら、それらに対する活動として、「Helm」「ksonnet」などの取り組みが存在します。完全な解決につながりませんが、大量のyamlファイルを人力で記述するといった事象からは一部解放されるかもしれません。

まとめ

　本連載では全3回で、Kubernetesの紹介、Kubernetesを利用するに至った背景、具体的に活用する上でのポイントについて説明しました。

　Kubernetesは、導入する上での前提や注意点が多々ありますが、適切な期待値と利用目的を持って導入すれば確実にプラスに働いてくれるツールです。

　少なくとも現時点ではmacOSやWindowsで、KubernetesはDockerに統合されており、容易に試してみることが可能です。まずはそこでいろいろと試してみた上で、「自身の組織でどう役立てるか」「役立てる上で何が足りないか」「足りない部分をどう補うか」を考えてもいいかもしれません。

　また、先に挙げた「Kubernetesをより良く活用するための前提条件」は、ベターであると昨今一般的に言われている開発プロセスの参考になるようにも思えます。その点で、実際に導入しなくても、自身の組織における開発プロセスの課題と、現代的な開発プロセスとの差異をあらためて見直してみてもいいかもしれません。

筆者紹介

藤原 涼馬

リクルートテクノロジーズ ITエンジニアリング本部 サイトリライアビリティエンジニアリング部 インフラストラクチャエンジニアリンググループ所属

ユーザー系SIerでのR＆D業務を経て2016年から現職。前職ではシステムの性能分析系技術の研究開発に従事。現在は主に、リクルートグループにおけるコンテナ仮想化をベースとしたシステムの設計・構築・運用に従事。

コンテナ管理ツール「Rancher」のコミュニティー（Rancher JP）のコアメンバーも務める。