🎯 レッスンの目的__HTMLTAG_68___
このレッスンを完了すると、次のことができるようになります:
- ✅ マイクロサービスのオンプレミス、クラウド、ハイブリッド デプロイメントの違いを理解する
- ✅ 実稼働システムのアーキテクチャの概要とすべてのコア コンポーネントを理解する
- ✅ スタック内の各テクノロジーを選択する理由を理解する (Kubernetes、Ceph、Patroni、Istio、ArgoCD...)
- ✅ コース全体のラボ環境をセットアップする
- ✅ 50 のレッスンのロードマップとセクション間のリンクを理解する__HTMLTAG_81___
パート 1: マイクロサービスにオンプレミスを使用する理由
1.1.実際のコンテキスト
クラウド ネイティブの時代においても、多くの組織は依然としてオンプレミスでの展開を選択しています。
📊 実際の統計 (2025-2026):
- ~60% のエンタープライズ ワークロードは依然としてオンプレミスまたはハイブリッドで実行されています (Gartner)
- スケーリング時にクラウドコストが毎年 30 ～ 40% 増加→「クラウド回帰」傾向
- 規制産業 (金融、医療、政府) にはデータ主権が必要__HTMLTAG_100___
- 遅延の影響を受けやすいアプリケーションはユーザー/デバイスに近い必要があります
1.2.オンプレミス、クラウド、ハイブリッドの比較
| 基準 | オンプレミス | パブリック クラウド | ハイブリッド |
|---|---|---|---|
| 初期費用 (CapEx) | 高 (ハードウェアを購入) | 低額 (従量課金制) | 平均 |
| 長期経費 (運用コスト) | 拡大縮小すると低くなります__HTMLTAG_139___ | 高さと予測不可能__HTMLTAG_141___ | ワークロードに応じて |
| _データ主権 | ✅ フルコントロール__HTMLTAG_151___ | ⚠️ 地域による | ✅ ほとんどがオンプレミス |
| _遅延 | ✅ 最低 | 地域依存 | 特殊なケースに適しています |
| カスタマイズ | ✅ 無制限 | プロバイダーによる制限 | 柔軟__HTMLTAG_179___ |
| 運用の複雑さ | ❌ 高 (自己管理) | ✅ 低 (マネージド) | 最高 |
| スケーリング速度 | ❌ 遅い (ハードウェアの購入) | ✅ 分 (自動スケール) | 柔軟 |
| コンプライアンス | ✅ 応答が最も簡単 | 共同責任が必要_ | 良い |
| _ベンダー ロックイン | ✅ いいえ_ | ❌ 高 (AWS/GCP/Azure) | 平均 |
1.3。オンプレミスを選択する必要があるのはどのような場合ですか?
✅ 次の場合はオンプレミスを選択する必要があります:
- ワークロードは安定しており、予測可能です (連続的にアップダウンが発生しない)
- 高度なコンプライアンス要件 (HIPAA、PCI-DSS、GDPR データ所在地)
- インフラストラクチャ投資 (データセンター、サーバー、ネットワーキング)
- クラウドの月額コストがしきい値を超えています (月額約 50,000 ～ 100,000 ドル以上)
- 運用経験のあるDevOps/SREチーム__HTMLTAG_248___
- _超低遅延が必要 (< 1ms giữa services) )
❌ 次の場合はオンプレミスを選択しないでください。
- 初期段階のスタートアップは市場投入までのスピードが必要
- ワークロードが急増し、予測が困難__HTMLTAG_260___
- チーム < 5 người, không có infra engineer
- _PoC/MVP を迅速に展開する必要がある__HTMLTAG_264___
パート 2: 全体的なシステム アーキテクチャ
2.1.全体的なアーキテクチャ図
コードブロック_0
2.2.コアコンポーネントと役割
レイヤー 1: インフラストラクチャ基盤
| 要素__HTMLTAG_280___ | テクノロジー | 役割 | レッスン__HTMLTAG_286___ |
|---|---|---|---|
| コンテナ ランタイム | コンテナ 2.x | CRI 標準に従ってコンテナを実行 | レッスン 5 |
| K8s オーケストレーション__HTMLTAG_302___ | kubeadm (K8s 1.31+) | HA コントロール プレーン、スケジューリング、自己修復__HTMLTAG_306___ | レッスン 5-7 |
| CNI ネットワーキング__HTMLTAG_312___ | Cilium (eBPF) | ポッド ネットワーキング、ネットワーク ポリシー、ハッブル可観測性__HTMLTAG_316___ | レッスン 8 |
| ロードバランサー | MetalLB | ベアメタル上のサービスに外部 IP を付与 | レッスン 9 |
| API サーバー HA | キープアライブ + HAProxy | K8s API エンドポイントの仮想 IP__HTMLTAG_336___ | レッスン 4 |
| クラスターの状態 | etcd (3 ノード) | K8 の分散 Key-Value ストア | レッスン 10 |
レイヤー 2: 分散ストレージ
| 要素__HTMLTAG_360___ | テクノロジー | 役割 | レッスン |
|---|---|---|---|
| ストレージ オーケストレーター | ルーク オペレーター | K8 で Ceph ライフサイクルを管理 | レッスン 11-12 |
| ブロック ストレージ | Ceph RBD | データベース (PostgreSQL、etcd) の PV | レッスン 13 |
| 共有ストレージ | CephFS | マイクロサービスのReadWriteMany__HTMLTAG_396___ | レッスン 14 |
| オブジェクト ストレージ | Ceph RGW (S3) | バックアップ、Loki ログ、Thanos メトリクス | レッスン 15 |
レイヤー 3: データレイヤー
| 要素 | テクノロジー | 役割 | レッスン__HTMLTAG_426___ |
|---|---|---|---|
| プライマリ データベース_ | PostgreSQL HA (CloudNativePG) | ACID トランザクション、リレーショナル データ | レッスン 16～17 |
| 接続プール | PgBouncer | 接続プーリング、DB 負荷を軽減__HTMLTAG_446___ | レッスン 18 |
| DB バックアップ | pgBackRest | 完全/増分バックアップ、PITR | レッスン 19 |
| メッセージ キュー | RabbitMQ HA | 非同期メッセージング、タスクキュー__HTMLTAG_466___ | レッスン 21 |
| イベント ストリーミング__HTMLTAG_472___ | カフカ (ストリムジ) | イベントソーシング、ログ集計 | レッスン 22 |
| キャッシュ | Redis HA | キャッシュ、セッション ストア、レート制限__HTMLTAG_486___ | レッスン 23 |
レイヤー 4: サービス メッシュとネットワーキング
| 要素 | テクノロジー | 役割 | レッスン__HTMLTAG_506___ |
|---|---|---|---|
| サービス メッシュ | Istio | mTLS、トラフィック管理、可観測性__HTMLTAG_516___ | レッスン 24～25 |
| Ingress コントローラー | NGINX Ingress | クラスターへの HTTP/HTTPS ルーティング | レッスン 26 |
| TLS 自動化_ | 証明書マネージャー | 証明書の自動発行/更新 | レッスン 26 |
| ゲートウェイ API | Istio + ゲートウェイ API | 次世代の Ingress、カナリア ルーティング | レッスン 27 |
レイヤー 5: プラットフォーム操作
| 要素__HTMLTAG_560___ | テクノロジー | 役割 | レッスン |
|---|---|---|---|
| GitOps | ArgoCD HA | Git からの宣言的デプロイメント | レッスン 28、30 |
| 梱包 | ヘルム | K8s マニフェスト テンプレート | レッスン 29 |
| 秘密 | Vault HA + ESO | シークレットの一元管理 | レッスン 31 |
| メトリクス | プロメテウス HA + サノス | メトリクスの収集、長期保存 | レッスン 32 |
| ダッシュボード | グラファナ HA | 視覚化、アラート | レッスン 33 |
| ログ | ロキ + 合金 | 一元化されたログ集約 | レッスン 34 |
| トレース | テンポ + OpenTelemetry__HTMLTAG_634___ | 分散トレース | レッスン 35 |
| ポリシー | カイバーノ | アドミッション コントロール、コードとしてのポリシー | レッスン 37 |
| ランタイムセキュリティ | ファルコ | 脅威の検出 | レッスン 38 |
| 画像セキュリティ | トリビー + ハーバー | 脆弱性スキャン、プライベート レジストリ | レッスン 39 |
| バックアップ | ヴェレロ | クラスターのバックアップ/復元 | レッスン 44 |
| _カオス テスト_ | カオス メッシュ | 回復力の検証 | レッスン 45 |
パート 3: 各テクノロジーを選択する理由
3.1. Kubernetes (kubeadm) — マネージド K8 を使用しないのはなぜですか?
_オンプレミスには EKS/GKE/AKS がありません。オプション:
| ツール | 利点_ | 欠点 | 関連 |
|---|---|---|---|
| kubeadm | 公式 K8s ツール、柔軟、実稼働グレード | 手動セットアップ、深く理解する必要があります | _✅ 制作_ |
| k3s | 軽量で取り付け簡単__HTMLTAG_731___ | 機能を削除し、代わりに SQLite を使用します etcd | エッジ/IoT |
| RKE2 | FIPS 準拠、Rancher 統合 | ベンダー固有 | Rancher ユーザー |
| Kubespray | Ansible ベース、再現可能 | 遅い、Ansible の複雑さ | 大規模クラスター |
👉 kubeadm を選択する理由: 製品グレードの公式ツールは、K8 の内部を最も深く理解するのに役立ちます。
3.2. Cilium CNI — なぜ Calico や Flannel ではないのでしょうか?
___コードブロック_1___3.3. Rook-Ceph — なぜ Longhorn や NFS ではないのでしょうか?
___コードブロック_2___3.4. Istio — なぜ Linkerd ではないのでしょうか?
___コードブロック_3___パート 4: 環境ラボのセットアップ
4.1.ラボ用の最小ハードウェア
コース全体を練習するには、少なくとも次のリソースが必要です:
オプション A: 強力なホスト上の VM (推奨)
コードブロック_4
_合計: ~26 vCPU、58GB RAM、520GB ディスク
オプション B: クラウド VM (AWS/GCP/Hetzner)
___コードブロック_5___オプション C: ベアメタル (本番環境と同様)
___コードブロック_6___4.2.ラボのネットワーク レイアウト
コードブロック_7
4.3. Vagrant を使用して VM を高速に作成する (オプション)
___コードブロック_8___コードブロック_9
4.4.すべてのノードの SSH キーを構成
___コードブロック_10___パート 5: 学習ルート 50 レッスン
5.1.セクション間の依存関係グラフ
コードブロック_11
5.2.推定所要時間
| セクション | 投稿番号 | 時間 | タイムライン (1 日あたり 2 時間) |
|---|---|---|---|
| パート 1: 基礎 | 4 | ~8 時間 | 第 1 週 |
| パート 2: K8s HA | 6 | ~14 時間 | 第 2 ～ 3 週 |
| パート 3: Rook-Ceph | 5 | ~11 時間 | 第 3 ～ 4 週 |
| パート 4: PostgreSQL__HTMLTAG_847___ | 5 | ~12 時間 | 第 5 週～第 6 週 |
| パート 5: MQ HA | 3 | ~8 時間 | 第 6 ～ 7 週 |
| パート 6: Istio | 4 | ~10 時間 | 第 7 ～ 8 週 |
| パート 7: GitOps | 4 | ~11 時間 | 第 9 ～ 10 週 |
| パート 8: 可観測性__HTMLTAG_887___ | 4 | ~10 時間 | 第 10 ～ 11 週 |
| パート 9: セキュリティ_ | 4 | ~10 時間 | 第 12 ～ 13 週 |
| パート 10: 導入 | 4 | ~9 時間 | 第 13 ～ 14 週 |
| パート 11: DR | 2 | ~5 時間 | 第 15 週 |
| パート 12: 操作 | 5 | ~15 時間 | 第 15 週～第 18 週 |
| _合計 | 50 | _~123h | ~18 週間 |
パート 6: コース内の規約と規約
6.1.命名規則
___コードブロック_12___6.2.レッスン内の記号
- 💡 ヒント: 役立つヒント、ベスト プラクティス
- ⚠️ 警告: エラーが発生する可能性があるので注意してください
- ❌ 危険: 運用環境では絶対に行わないでください
- 📋 チェックリスト: チェックリスト
- 🔬 詳細: 技術的説明
- 🛠️ ラボ: 実践
💡 重要なポイント
- オンプレミスのマイクロサービス データ主権、予測可能なコスト、超低遅延を必要とする組織に適しています
- Kubernetes HA はオーケストレーション プラットフォームであり、CNCF ツール エコシステムと組み合わせて運用プラットフォーム を作成します。
- フルスタック__HTMLTAG_1003___には、インフラストラクチャ→ストレージ→データ→ネットワーキング→プラットフォーム→セキュリティ の6つのレイヤーが含まれています
- 各テクノロジーは次の基準に基づいて選択されます次の基準に基づいて選択されます: 製品グレード、CNCF 支援、アクティブなコミュニティ
- ラボ環境には、合計約58GBのRAM__HTMLTAG_1012___を備えた少なくとも7つのVM（マスター3つ、ワーカー3つ、LB1つ）が必要です。
🎯 演習
演習 1: インフラストラクチャ要件の評価__HTMLTAG_1018___
シナリオの場合: フィンテック企業は、20 のマイクロサービスをデプロイし、10,000 リクエスト/秒を処理し、500 GB のデータを保存し、PCI-DSS 準拠を必要とする必要があります。
- 必要なノードの数を計算します (コントロール プレーン、ワーカー、ストレージ)
- CPU、RAM、ストレージの推定合計
- ネットワーク トポロジ図を描画
- 上記のスタックから必要なコンポーネントをリストします
演習 2: ラボ環境のセットアップ__HTMLTAG_1032___
- オプション A またはオプション B を使用して 7 つの VM を作成
- VM 間のネットワークの構成
- SSH キーベースの認証のセットアップ
- すべてのノード間の ping 接続を確認
- 各 VM の IP とホスト名を記録します
演習 3: テクノロジーの比較__HTMLTAG_1046___
2 つのテクノロジーのペアを詳細に調査して比較します:
- Cilium 対 Calico: パフォーマンス ベンチマーク、機能、コミュニティ
- Rook-Ceph と Longhorn: スケーラビリティ、機能、運用の複雑さ
📚 次の投稿
__HTMLTAG_1059___レッスン 2: ハードウェア計画とネットワーク トポロジでは、実稼働環境の CPU/RAM/ディスク、VLAN、ボンディング、および MTU を使用したネットワーク トポロジ設計の詳細なサイジング計算について詳しく説明します。