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

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

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

インフラアーキテクト、アプリ開発者、運用／インフラ技術者の視点で

　本連載「コンテナベースのCI/CD本番事例大解剖」では、リクルートテクノロジーズが取り組んだ事例を基に、Kubernetes、コンテナ技術を活用したCI（継続的インテグレーション）/CD（継続的デリバリー）基盤におけるサービス開発について解説します。事例は、リクルートジョブズが運営する「ジョブオプLite」という、「採用ホームページ」の作成、採用応募の管理を行うためのWebサービスです。

　筆者の所属するリクルートテクノロジーズは、IT、マーケティングテクノロジーをリクルートグループ全体に横断的に適用し、ビジネスの成長に寄与することを目的に、さまざまな取り組みを進めています。その中で、筆者と今回の連載に携わるメンバーは、サービス開発のアジリティー向上を目的としてさまざまな取り組みを行ってきました。

　この取り組みの一つが、DockerとKubernetesを中心としたコンテナ技術の活用です。2018年に「先行事例に学ぶKubernetes企業活用の現実」と題して、取り組み内容について連載しましたが、連載から半年以上たち、DockerとKubernetesを活用した成果や、「取り組み中に生じた課題をいかにしてクリアしたか」といったリアルな経験が蓄積されてきました。

　本連載では、これらの成果と課題解決に向けた活動、その結果を紹介します。

　第1〜3回では、「Kubernetes、Dockerをコア技術に据えて、サービスを構築した際に、開発、保守運用においてどのような影響があったのか」について、インフラアーキテクト、アプリ開発者、運用／インフラ技術者それぞれの視点から紹介します。

　最終回では、今後さらにCI/CD基盤を洗練させるために取り組んでいる内容や、「現時点で、どのような取り組みを進めているのか」などを紹介します。

　連載初回となる今回は、インフラアーキテクトの視点から技術選定の考え方について解説します。

インフラアーキテクトの役割

　まず、インフラアーキテクトの役割を簡単に説明しておきます。インフラアーキテクトが担う責務とは下記のようなものです（あくまでも一例なので他にも多々あると思います）。

• サービスの動作環境の選定（オンプレミスかパブリッククラウドかなど）
• ミドルウェアの選定、設計
  • 機能／非機能要件に合わせてより良いプロダクトを選定、設計する
  • ミドルウェアの提供形態（マネージド or 非マネージド）を検討する
• 非機能要件のすり合わせ、実現方法の大枠の策定
  • 非機能面での各種要件を測定するための監視、モニタリングの大枠を策定する
  • アプリケーション面の監視、モニタリングについてはアプリケーションエンジニアとのすり合わせも行う
• コード品質を支えるためのCIやデプロイプロセスの大枠を策定する（具体的なアプリケーションロジック、それを記述するための言語の選定といった部分以外には、全体的に関わる）

今回扱う事例に求められた要件

　今回扱う事例（ジョブオプLite）は、一般的なWebアプリケーションであり、サービスとしての特殊な要件はありません。また、完全新規開発のサービスであり、全ての技術選定をゼロベースで行えました。

　しかし、技術を使ったビジネス貢献の最大化、リスクの低減や排除といった観点で下記のような要件がありました。

1. 今後の成長を見込んだスケーラビリティの高い構成を実現する
2. 特定のクラウドベンダーへのロックインを、できる限り回避する
3. 中期的視点での運用コストの削減

　これらの要件に基づいて技術の選定および、全体のアーキテクチャの設計を行いました。

　例えば「オンプレミスかパブリッククラウドか」という選定においては、オンプレミスではなく、パブリッククラウドサービス（今回の事例ではAWS（Amazon Web Services））を選定することになりました。なぜなら、上記の要件1「スケーラビリティの高い構成」と要件3「中期的視点での運用コストの削減」を実現するためには、オンデマンドで必要な計算リソースを、低コストで確保できなければならないからです。

　ここからは、今回の主題である「インフラアーキテクトとして、コンテナベースのサービス開発を取り組む前後で考えた事柄」を、技術選定をベースに解説します。技術選定においては、まず目的を明確にすることを重視しました。

　具体的な目的がないテクノロジーの活用は、お勧めできません。これは、要素技術まで含めて採用意図を明確にすることで、プロジェクトにおける種々の判断のよりどころを明確にした上でプロジェクトを進めたいからです。

　判断の根拠が不明瞭な場合、プロジェクトに参加しているメンバーが納得感を持って開発を進めることが難しくなります。開発に携わるメンバーが納得感を持てない状態では、モチベーションが低下し、開発の生産性低下につながりかねません。

　なおDockerとKubernetesについては、すでに技術は選定されているといえるので、目的を明確にするためのプロセスのみを解説しています。

DockerとKubernetesは、The Twelve Factorsを充足するサービスの構築を手助けしてくれる

　本稿を理解する際に必要な概念に、「The Twelve Factors App」があります。これはアジリティーの高いWebサービスを構築するための方法論です。

　DockerとKubernetesは、The Twelve Factors Appを構成する12の要素「The Twelve Factors」（図1）を充足したサービスを構築する手助けをしてくれます。具体的な要素については後述します。

図1　「The Twelve Factors」（「The Twelve Factors App」から引用）