物流SaaS

顧客は1日に数万件の注文を扱う物流サービスです。夕方やセール時に負荷が集中し、提携する小売チェーンには厳格なSLAを約束していました。インフラは場当たり的に拡大し、VPSが分散し、設定は「各サーバーに」残り、wikiの手順に沿って手作業でデプロイしていました。リリースのたびに夜間作業と停止が発生し、ピークのたびに注文を失うリスクがありました。年末前のセールでプラットフォームが4時間停止し、提携先へ補償を支払った事故を機に相談がありました。

事業を止めずにプラットフォームを管理可能なインフラへ移行します。Infrastructure as

Code、自動デリバリー、コンテナ化とオーケストレーション、可観測性、予測可能な障害復旧を整備します。創業者は成功条件を「営業時間内に、ダウンタイムなしで、SSHアクセスを持つ人に頼らずデプロイすること」と定義しました。

実績のある順序で進めました。まずコンテナと再現可能な環境を整え、次にデリバリーを自動化し、その後でオートスケーリング付きのオーケストレーションを導入しました。

• インフラを監査しました。サービスと依存関係の図、ピーク負荷の測定、障害につながりやすい手作業の一覧を作成しました。
• サービスをコンテナ化しました。ビルド方法を統一し、設定をコードから環境変数へ移し、同一構成のdev/stage/prodを用意しました。
• Terraformでインフラをコード化しました。環境はリポジトリから展開し、クラウド事業者のコンソールでの手動変更は禁止しました。
• GitLab CIパイプラインを構築しました。テストとイメージのビルドを自動化し、stageには即時デプロイ、prodにはレビュー後にボタンでデプロイします。ロールバックは一操作で行えます。
• オートスケーリング付きのKubernetesへ移行しました。夕方やセールのピークには、緊急の手作業ではなくプラットフォームが追加インスタンスを起動します。
• レイテンシ、エラー、トラフィック、飽和度というゴールデンシグナルを中心に監視とアラートを導入し、当番とエスカレーション手順も整えました。
• バックアップと災害復旧を設定しました。復旧手順を定め、stageで障害訓練を行い、実際のMTTRを測定しました。

最も価値があったのは技術ではなく、責任の置き方を変えたことです。インフラは「SSH権限を持つ人」に依存しなくなりました。デプロイは再現可能で、環境はコードから復元でき、最初の顧客が連絡してくる前にダッシュボードで障害が見えます。これにより停止は大惨事ではなく、明確な手順と測定可能な復旧時間を伴う日常のインシデントになります。

次のサイクルでインフラを発展させる領域：

• FinOpsの実践。コスト異常をアラートし、チーム別に費用を透明化します。
• GitOpsの導入。prodの状態をリポジトリに記述し、変更はpull request経由に限定します。
• マルチリージョン化。重要サービスを複製し、クラウド事業者の障害への耐性を高めます。