1.1 昔のインフラと課題

かつて、アプリケーションは物理サーバー上に直接デプロイされていました。サーバーごとに設定が異なりやすく、特定のアプリケーションしか動かせない「サイロ化」が発生。リソースの無駄も多く、一つのサーバーに問題が起きると、そこで動く複数のアプリケーションが停止するリスクがありました。

その後、仮想化技術（仮想サーバー、VM: Virtual Machine） が登場しました。一つの物理サーバー上に複数の仮想サーバーを動かすことで、リソースの効率利用が進みました。しかし、仮想サーバーはOSを含んだ完全な環境です。そのため、起動に時間がかかり、リソース消費も大きいという課題がありました。

1.2 コンテナの登場とメリット

ここで登場するのがコンテナです。コンテナは、アプリケーションとその実行に必要なすべてのもの（ライブラリ、設定ファイルなど）を一つにまとめて「カプセル化」したものです。仮想サーバーと違い、OS全体を含むわけではありません。同じホストOSのカーネルを共有するため、さらに軽量です。そのため、非常に軽量で高速に起動します。

例えるなら、物理サーバーは「一戸建ての家」、仮想サーバーは「マンションの一室」、そしてコンテナは「引越し可能な箱詰めの荷物」です。ホストOSの上で、**アプリケーションとその実行環境だけを「箱詰め」**にするイメージです。

この「どこへでも同じ状態で動く」という特性が、現代の高速な開発サイクルには非常に重要です。開発者のPCで動いたものが、テスト環境、本番環境でも同じように動くため、「私の環境では動いたのに！」という問題が激減します。

1.3 Kubernetesとは？その役割と仕組み

このコンテナは非常に便利ですが、アプリケーションが数十、数百、数千個ものコンテナで構成されるようになると、手作業でそれらを管理するのは不可能です。

• どのサーバーでどのコンテナを動かすか？
• 負荷が増えたら、このコンテナをあと3つ増やそう
• このコンテナが壊れたら、自動的に作り直して
• 新しいバージョンのコンテナに、安全に切り替えよう

こうした、大量のコンテナを「自動で、効率的に、安定して」管理・運用してくれるシステムこそが、Kubernetesなのです。これはまさに「コンテナオーケストレーション」と呼ばれる分野の代表格です。Googleが開発し、現在はCNCF（Cloud Native Computing Foundation）が管理しています。

なお、Kubernetes上のリソース（アプリケーションの動作設定など）の管理は、単に設定ファイル（YAMLファイル）を手書きするだけでなく、HelmやArgo CD（ギットオプス）といったツールを組み合わせることで、より効率的かつ安全に運用できます。詳しくは後述します。

2.1 システム構成とマイクロサービス群

Boxのようなシステムは、以下のような複数のマイクロサービスに分割して実装されます。これらのサービスはそれぞれ独立したコンテナとしてKubernetesのPod上で動作します。

• ファイルアップロード/ダウンロードサービス: ユーザーからのリクエストを処理します。
• ストレージ管理サービス: 実際のファイルデータをクラウドストレージと連携して保存・管理します。オンプレミスやハイブリッド構成も考慮できます。
• メタデータ管理サービス: ファイルの所有者、サイズ、バージョンなどの情報をデータベースで管理します。
• ユーザー/権限管理サービス: ユーザー認証とファイルへのアクセス権限を管理します。
• 同期サービス: 複数デバイス間でのリアルタイム同期を行います。
• 検索サービス: ファイルの内容やメタデータを高速に検索します。
• プレビュー/変換サービス: ドキュメントや画像をブラウザで表示できるよう変換します。
• 通知サービス: ファイルの変更などをユーザーに通知します。
• API Gateway: 外部からのリクエストを受け付け、適切な内部マイクロサービスにルーティングします。

2.2 技術的なポイントと注意点

BoxのようなシステムをKubernetes上で構築・運用するには、インフラの設定からアプリケーションのデプロイまで、膨大な作業が発生します。これらを効率的かつ確実に進めるために、「TerraformによるIaC（Infrastructure as Code）」という考え方が非常に重要になります。

4.1 Kubernetesリソース管理の住み分け

Terraformは主にクラウド基盤（VPCやKubernetesクラスター自体）の管理に強く、Kubernetes上のアプリケーションレイヤーはHelmやArgo CDといったGitOps（ギットオプス：アプリケーションやインフラの構成情報をGitで一元管理し、その状態と実際のシステムを常に一致させる手法）ツールの方が管理しやすいという住み分けが一般的です。

4.2 Pulumiの位置づけと選択肢

Terraformは宣言型の設定ファイル（YAMLやHCL）でインフラを管理しますが、PulumiはTypeScriptやPythonなどの一般的なプログラミング言語を使って、より柔軟にインフラをコード化できるツールです。特にアプリ開発者にとって親しみやすく、IaCとアプリケーション開発の境界をよりシームレスにできます。これにより、IaCとアプリケーションコードの境界がより柔軟になり、さらなる自動化と統合が実現可能です。

4.3 DevOps文化と責任範囲の変化

本文では役割分担を明確に記載しましたが、現代のDevOpsでは、インフラとアプリケーションの責任範囲が重なる場合も増えています。「You build it, you run it（開発したものが動く責任は開発者自身が持つ）」という文化のもと、アプリ開発者自身がKubernetesリソースの定義やデプロイまで担当するケースが増えています。この場合、インフラチームやプラットフォームチームは、開発者が安心して使えるような共通基盤や自動化されたパイプラインを提供する役割を担います。