フリーランスエンジニアとして複数のプロジェクトを手掛けてきた中で、コンテナオーケストレーションほど現場での理論と実践のギャップを感じる技術領域は少ない。
最近のプロジェクトでは、従来のDocker Composeベースの構成から本格的なKubernetes環境への移行を担当した。システムアーキテクチャ設計において、単なる技術選択を超えた運用面での深い洞察が求められる案件だった。
システム設計における判断プロセス
クライアントの要求は「スケーラブルで保守性の高いマイクロサービスアーキテクチャ」という一見明確なものだった。しかし、実際のビジネス要件を深掘りすると、以下の課題が浮き彫りになった。
技術的制約と現実的判断
- トラフィック予測：月間100万PVから急激な成長を想定
- チーム体制：DevOpsエンジニア不在、開発者3名体制
- 運用予算：AWSコスト月10万円以下の制約
- 技術的負債：レガシーデータベーススキーマとの共存が必要
これらの制約下で、理想的なCloud Nativeアーキテクチャではなく、段階的移行戦略を選択することになった。
実装フェーズでの技術選定
第1段階：コンテナ化とCI/CDパイプライン構築
まずはアプリケーション層のコンテナ化から着手した。Docker化においては、マルチステージビルドを活用してイメージサイズを60%削減。本番イメージサイズを150MBまで圧縮できたことで、デプロイ時間が大幅に短縮された。
CI/CDパイプラインでは、GitHub ActionsとAWS CodePipelineの組み合わせを採用。単純なGitHub Actions単体構成と比較して、AWS内でのデータ転送コストを考慮した結果だ。
第2段階：Kubernetesクラスタ設計と最適化
EKS（Elastic Kubernetes Service）を選択し、ワーカーノードはSpot Instancesを積極活用。コスト最適化のため、Cluster Autoscalerと組み合わせて需要に応じた自動スケーリングを実装した。
重要な学びは、Kubernetesの設定値チューニングだった。特に：
- Resource Requests/Limits: CPUリクエストを実際の使用量の120%に設定
- HorizontalPodAutoscaler: CPU使用率70%をトリガーに設定
- PodDisruptionBudget: 最低50%のPodが常に稼働するよう調整
これらの細かな調整により、サービス可用性99.9%を達成しながら、リソースコストを30%削減できた。
運用フェーズでの課題と解決策
モニタリング・アラート体制の構築
Prometheus + Grafanaの組み合わせでメトリクス収集基盤を構築したが、アラート疲れが深刻な問題となった。初期設定では数百のアラートが日次で発生し、重要な障害の検知が困難になっていた。
解決策として、アラート階層化を実装：
- Critical: 即座対応（サービス停止レベル）
- Warning: 1時間以内対応（性能劣化）
- Info: 翌営業日対応（リソース使用量通知）
この階層化により、本当に重要なアラートに集中できる運用体制が確立できた。
ログ管理とトレーサビリティ
マイクロサービス環境でのログ管理では、分散トレーシングが不可欠だった。Jaegerを導入し、リクエストごとの処理フローを可視化。
特に効果的だったのは、ビジネス重要度に応じたサンプリング率の調整だ：
- 決済処理：100%トレース
- 商品検索：10%トレース
- 静的コンテンツ：1%トレース
この調整により、ストレージコストを50%削減しながら、重要な処理の完全なトレーサビリティを確保した。
セキュリティとコンプライアンス対応
Container Security Scanningの実装
TrivyとClair の両方を CI/CDパイプラインに統合し、脆弱性のあるイメージのデプロイを防止。さらに、Admission Controllerでruntime時のポリシー実行も実装した。
実際の運用では、Critical レベルの脆弱性が発見された際の対応フローが重要だった：
- 自動的なデプロイ停止
- セキュリティチームへの即時通知
- 修正版の優先的なビルド・テスト
- ホットフィックスとしての緊急デプロイ
このフローにより、脆弱性発見から修正適用まで平均4時間以内を実現している。
パフォーマンス最適化の実践
Database Connection Poolingの調整
マイクロサービス環境では、データベース接続が分散することでConnection Pool設定の重要性が増す。PostgreSQLを使用していたが、サービスごとの適切な接続数設定に苦労した。
最終的に、PgBouncerを導入してConnection Poolingを一元管理。各サービスの特性に応じて：
- Read-Heavy Service: 20接続
- Write-Heavy Service: 10接続
- Batch Processing: 5接続
この調整により、データベース負荷を40%削減し、レスポンス時間も平均200ms改善した。
CDNとエッジキャッシングの活用
CloudFlareを活用したエッジキャッシング戦略では、APIレスポンスの部分キャッシュが効果的だった。商品情報のような比較的静的なデータは15分、ユーザー固有情報は除外という粒度でキャッシュ設定を実装。
キャッシュヒット率85%を達成し、オリジンサーバーへの負荷を大幅に軽減できた。
技術選択の振り返りと教訓
成功した判断
- 段階的移行: ビッグバン移行ではなく、段階的なコンテナ化
- 運用優先設計: 理想的なアーキテクチャよりも運用可能性を重視
- コスト意識: 技術的美しさとビジネス制約のバランス
見直すべき判断
- 初期のアラート設定: 過度に細かいメトリクスでアラート疲れ
- ストレージ戦略: 初期段階でのパフォーマンス重視によるコスト増
- ドキュメント管理: 技術的実装に集中してドキュメント整備が後手
フリーランスエンジニアとしての学び
このプロジェクトを通じて、技術選択における「正解」は文脈に大きく依存することを再認識した。最新技術への技術的興味と、ビジネス制約下での現実的判断のバランスを取ることが、フルスタックエンジニアとしての真価だと思う。
特に重要なのは、クライアントの技術的成熟度と運用体制を正確に把握することだ。Kubernetesのような高度な技術も、適切な運用体制なしでは技術的負債となりかねない。
次のプロジェクトでは、Serverless アーキテクチャでの同様な課題に取り組む予定だ。コンテナオーケストレーションで学んだ運用視点での判断プロセスが、きっと活かされるだろう。
