1. クラウドネイティブ — CNCFの定義
CNCF（Cloud Native Computing Foundation）によると、クラウドネイティブとは、パブリック、プライベート、ハイブリッドクラウドなどの動的環境でスケーラブルなアプリケーションを構築・実行する方法であり、コンテナ、マイクロサービス、宣言型API、イミュータブルインフラストラクチャを活用します。
| 原則 | 意味 | 例 |
|---|---|---|
| Containerized | アプリと依存関係をパッケージ化 | Dockerイメージ |
| Dynamically orchestrated | 自動スケジューリング、スケーリング、自己修復 | Kubernetes |
| Microservices | 疎結合、単一責任 | 認証サービス、決済サービス |
| Declarative APIs | 手順ではなく望ましい状態を記述 | kubectl apply -f deployment.yaml |
| Immutable infrastructure | 実行中のものは変更せず、置き換える | 新イメージバージョン → ローリングアップデート |
2. マイクロサービスvsモノリス
MONOLITH MICROSERVICES
───────────────────── ──────────────────────────────
┌──────────────────┐ ┌────────┐ ┌────────┐ ┌─────┐
│ Auth │ UI │ │ Auth │ │ Cart │ │ UI │
│ Cart │ API │ │Service │ │Service │ │Svc │
│ Payment │ DB │ └────────┘ └────────┘ └─────┘
└──────────────────┘ │ │ │
Deploy as 1 unit └─── API Gateway ───┘
│
Client/Browser| 観点 | モノリス | マイクロサービス |
|---|---|---|
| デプロイ | 一括デプロイ | サービスごとに独立 |
| スケーリング | アプリ全体をスケール | ボトルネックのサービスのみスケール |
| 複雑さ | 低い（単一コードベース） | 高い（分散システム） |
| 障害分離 | 1つのバグで全体がダウン | 障害はサービス内に限定 |
| 技術 | 単一スタック | ポリグロット（サービスごとに最適なツール） |
3. 12-Factor App
12-Factor Appメソドロジーはクラウドネイティブアプリケーションのベストプラクティスを定義しています：
| # | ファクター | クラウドネイティブでの実践 |
|---|---|---|
| 1 | Codebase | アプリごとに1リポジトリ、複数デプロイ |
| 2 | Dependencies | 明示的に宣言（package.json、go.mod） |
| 3 | Config | 環境変数に保存（ConfigMap、Secrets） |
| 4 | Backing services | DB、キャッシュ = URLで接続するアタッチドリソース |
| 5 | Build/Release/Run | 厳密な分離（CIでビルド、CDでデプロイ） |
| 6 | Processes | ステートレスプロセス、状態は外部に保存 |
| 7 | Port binding | ポート経由でサービスを公開（Webサーバーレイヤー不要） |
| 8 | Concurrency | プロセスモデルでスケール（HPA） |
| 9 | Disposability | 高速起動、グレースフルシャットダウン |
| 10 | Dev/Prod parity | 環境間で同じツール/サービスを使用 |
| 11 | Logs | イベントストリームとして扱う（stdout、ファイルではない） |
| 12 | Admin processes | ワンオフの管理タスクをJobとして実行 |
試験のポイント： ファクター3、6、9、11はKCNAの問題によく出ます。ファクター3（環境変数にconfig）→ ConfigMap/Secret。ファクター6（ステートレス）→ 外部ストレージを使う理由。ファクター11（ログはストリーム）→ stdout → ログアグリゲーター。
4. Service Mesh
マイクロサービスが増えると、mTLS、リトライ、サーキットブレーカー、オブザーバビリティの管理が必要になります。Service Meshは各Podにサイドカープロキシを注入することでこの問題を解決します。
Without Service Mesh: With Service Mesh (Istio):
App A ──────────────► App B App A ──► [Envoy] ──► [Envoy] ──► App B
(manual TLS, retry code) sidecar sidecar
(auto mTLS, metrics, retry, tracing)| 機能 | Service Meshが提供するもの |
|---|---|
| mTLS相互認証 | サービス間のトラフィックを自動暗号化 |
| トラフィック管理 | カナリア、A/B、重み付きルーティング |
| オブザーバビリティ | 自動メトリクス、トレーシング、アクセスログ |
| レジリエンス | リトライ、タイムアウト、サーキットブレーカー |
5. チートシート
| 試験の質問 | 回答 |
|---|---|
| CNCFが定義するクラウドネイティブの要素は？ | コンテナ、マイクロサービス、宣言型API、イミュータブルインフラ |
| 12-Factorに従ってconfigをどこに保存すべき？ | 環境変数（ハードコードしない） |
| 12-Factorに従ったログの扱い方は？ | ストリームとして扱う（stdout/stderr） |
| Service MeshはPodに何を注入する？ | サイドカープロキシ（Envoy） |
| マイクロサービスはどの部分をスケールする？ | ボトルネックのあるサービスのみ |
6. 練習問題
Q1: 12-Factor Appメソドロジーに従って、アプリケーションはデータベース接続文字列をどのように保存すべきですか？
- A) ソースコードにハードコード
- B) リポジトリにコミットされる設定ファイル
- C) 環境変数として（Kubernetes ConfigMapまたはSecret） ✓
- D) ビルド引数としてコンテナイメージに
解説：ファクター3（Config）は「設定を環境に保存する」と述べています。Kubernetesでは、機密でない設定にはConfigMap、機密の値にはSecretを使用し、環境変数として注入します。
Q2: マイクロサービスアーキテクチャでService Meshを使用する主な利点は何ですか？
- A) コンテナオーケストレーションのKubernetesを置き換える
- B) アプリケーションコードを変更せずにインフラレベルのネットワーク機能（mTLS、リトライ、オブザーバビリティ）を提供する ✓
- C) アプリケーション設定を保存する
- D) コンテナ再起動時にアプリケーション状態を永続化する
解説：Service Meshはサイドカープロキシを介して横断的関心事（セキュリティ、オブザーバビリティ、レジリエンス）をインフラ層に移動します。開発者は各サービスにリトライロジックやmTLSを実装する必要がありません。
Q3: 「イミュータブルインフラストラクチャ」を従来のインフラストラクチャと区別する特徴は何ですか？
- A) サーバーは再起動されない
- B) 実行中のシステムはインプレースで変更されるのではなく、置き換えられる ✓
- C) 設定変更には手動承認が必要
- D) インフラストラクチャはYAMLファイルのみで定義される
解説：イミュータブルインフラストラクチャとは、実行中のコンテナを更新/パッチすることなく、新しいイメージをビルドしてデプロイし、古いコンテナを置き換えることを意味します。これにより構成のドリフトが排除され、再現性が向上します。