対象読者
- 社内でアプリケーション開発者向けにインフラの設計・実装、利用サポートなどを行っているエンジニアの方
コンテナ仮想化とDockerを取り巻く環境
コンテナ仮想化ツール「Docker」といえば、もう知らない人はいないかもしれません。Linuxネームスペースを活用して、アプリケーションを「コンテナ」という仮想環境に閉じこめることで、アプリケーションの保守性や運用性、セキュリティを高めるトレンドは、ここ数年でますます勢いを増しています。
コンテナの適用範囲は幅広く、例えば以下の用途ですでに社内利用されている方も多いのではないでしょうか。
Continuous Integration（継続的インテグレーション）
CIジョブをコンテナ内で実行することで低コストと高パフォーマンスを両立するCircleCIのようなSaaSの登場。
環境構築の自動化
コンテナの可搬性などを活用して、開発環境を頻繁に作成・破棄。
マイクロサービスの隆盛と課題
一方、サービスごとにチームを分け、チームとサービス間はAPIによって連携する、という古くはサービス指向アーキテクチャ（SOA）、近年はマイクロサービスアーキテクチャと呼ばれているアーキテクチャが、大小さまざまな企業でよく見られるようになってきました。
マイクロサービスの運用にはいくつかチャレンジングな点がありますが、中でも問題となりやすいのは「サービスの開発・運用基盤のメンテナンスコスト」ではないでしょうか。例えば、皆さんの現場でも新規サービスを開発するたびに以下の作業が発生することが多いと思います。
- デプロイ自動化（ステージング、本番、PRレビュー環境）
- CIパイプラインの実装（並列・分散テスト、単体・結合・E2Eテスト）
- 開発環境構築
- Observabilityの確保（リソースモニタリング、ログ集約、分散トレース）
- 開発者・運用者の各種アカウント管理とアクセスコントロール
仮にマイクロサービスが100個あったとして、その100個がそれぞれの方法で上記のような開発・運用基盤の整備を個別にやっていたとしたら、大変な非効率ですよね。本当はコードを書いてボタンをワンクリックしたら安全に、即時で本番サービスに反映されてほしい。現実はそれと程遠い状況です。
ネタばらしをすると、本記事ではこの課題を解決する基盤としてKubernetes on AWSを活用することを提案します。しかし、これをそうした技術なしで解決している企業も多くあるはずです。なぜそのような違いが生まれるのでしょうか？
手運用とワンオフスクリプトの限界
日本の多くの企業は開発・運用基盤の開発と提供そのものをビジネスとしてしているのではなく、それを使って他のビジネスを行っているはずです。売り上げに直結するサービスと、そうではないこうした開発・運用基盤への開発投資のバランスは簡単に決められるものではないと思いますが、確実に言えることは2つあります。
- アプリケーション開発者はアプリケーション開発に集中したい
- 開発・運用基盤の投資対効果は高ければ高いほど良い
その結果、現場でよく行われるのは「手運用やワンオフスクリプトでやれるところまでやる」という戦略です。例えばクラウドプロバイダとしてAWSを採用している企業であれば、AWSのマネージドサービスを前提に、それをできるだけ少ないプログラミングで効率よく運用する、ということです。早すぎる抽象化同様に、早すぎる自動化もまた投資リスクの高い行為ですから、当然ともいえます。
この戦略は基本的によくワークしますが、問題を2つだけ挙げるとすると、
- 手運用で出せる生産性には限界がある
- ワンオフスクリプトで済む自動化には限界がある
ということがあります。
この2つの問題は、マイクロサービスアーキテクチャを採用した現場では以下の現象として現れることがあります。
- 把握しきれないくらい大量のワンオフスクリプトがあるが、それを実際に活用できる人が少ない
- 微妙に自動化しきれない作業が積み重なって運用者の工数を圧迫する
一方で、基盤の運用と異なり、自社の主たるビジネスを支えているWebサービスがこうした状態に陥ることは少ないのではないでしょうか。
多くの企業のWebサービスにはリッチな管理画面が用意されていますし、運用者がWeb UI上で必要な作業を完結できるような仕組みや、最低でも手順書などが用意されていることと思います。いざとなれば、アプリケーションコードをREPLにロードして、そこから必要な作業をスクリプトによって実施する、といったこともできるでしょう。
なぜ、開発・運用基盤でそれに匹敵するものが用意できないのでしょうか？ それは、多くの企業で投資対効果に見合わないからです。
例えば、Ruby on Railsは良くも悪くもWebアプリケーションを統一されたフレームワークとプログラミング言語によって構造化し、再利用可能にしてくれます。そうすることで初めて、前述した現場での手順書化や管理画面の開発、REPLからの作業のスクリプト化などが現実的な工数で行えるようになります。
一方、われわれが直面している「マイクロサービス」というものは、Webアプリケーションと異なり、あまりにスコープが広すぎます。結果、「マイクロサービスにおけるRails」のようなものはこれまで存在しませんでした。こうした状況では、現場は構造化や再利用性の確保がされていないツールを、人の限られたリソースでなんとか活用して運用を回すしかありませんでした。
巨大なWebサービスを運用する企業では、同じ開発投資に対して得られるコスト削減や運用効率向上の効果の絶対値が高いため、それほど大きな問題となっていないことも多いです。著名なWebサービスを提供している会社が、たくさんOSSを公開しているのを見たことはないでしょうか。企業単独でOSSを開発・公開するためには、ワンオフの社内ツールとは桁違いの費用がかかります。しかし、規模の大きな企業では、それでもペイするということです。
