ケイパビリティ
私たちは、AWS、Microsoft Azure、Google Cloud上のクラウド基盤を、アプリケーションの要件から外側へ向かって設計します。ネットワーク、コンピュート、データの耐久性、復旧、コストを意図をもって決定し、コードとして記述し、自動化によって運用します。
アプリケーションをクラウドにデプロイすること自体は小さな作業です。それが動くインフラを設計することは、別の専門領域です。トラフィックがどこから入るのか、状態をどこに置くのか、何が何から独立して障害を起こすのか、キャパシティが需要にどう追従するのか、処理単位あたりのコストはいくらか。こうした決定が、アプリケーションコードの最適化に着手するはるか前に、可用性、レイテンシ、セキュリティの上限を決めます。
インフラは、アプリケーション要件、セキュリティ、レジリエンス、性能、経済性を軸に設計すべきだというのが当社の原則です。この順に把握していき、5つすべての緊張関係を保ったまま設計します。レイテンシに敏感なトランザクションサービス、バッチ分析パイプライン、GPU推論ワークロードでは、必要なネットワークトポロジー、スケーリングのシグナル、復旧戦略がそれぞれ異なります。汎用的なランディングゾーンから始めて後からワークロードを当てはめると、重要でない箇所にコストがかかり、重要な箇所が脆い基盤になります。
構築するものはすべてInfrastructure as Code（IaC）として表現します。通常はTerraformを用い、各環境を同じモジュールから作成し、パイプラインを通じて昇格させます。これにより基盤はレビュー可能、再現可能、復旧可能になります。リージョン、アカウント、クラスターを記憶ではなくリポジトリから再構築でき、本番へのあらゆる変更に作成者、差分、ロールバック手段が残ります。
エンジニアリング領域
ほかのすべてが継承する土台として、アカウント、サブスクリプション、プロジェクトの構造を設計します。環境の分離、アイデンティティの境界、ネットワークのセグメンテーション、ガードレールがその対象です。ワークロードが侵害された場合や変更を誤って適用した場合でも、影響が一つの境界内にとどまるように構造を選びます。プロバイダーの選定は好みではなく、ワークロードと組織の既存資産に基づいて行います。
クラウドのネットワーク設計は、攻撃対象領域とレイテンシの下限の両方を決めます。アドレス計画、サブネットの階層、マネージドサービスへのプライベート接続、そしてエッジからワークロードまでリクエストがたどる経路を設計します。ロードバランシングは多層構成とし、エッジでグローバルルーティングとTLS終端、リージョンの入口でレイヤー7ルーティング、クラスター内でサービス間トラフィックを扱います。
ワークロードをDockerでパッケージ化し、運用上の複雑さに見合ったオーケストレーション層で実行します。Kubernetesは、そのスケジューリング、拡張性、マルチテナントのモデルが運用コストに見合う場合に採用し、見合わない場合はマネージドコンテナサービスを使います。クラスター設計では、ノードプール、Podセキュリティ、リソースのrequestsとlimits、Disruption Budget、アップグレード手順までを扱います。
インフラの変更は、アプリケーションコードと同じレビュー、テスト、昇格のプロセスを通ります。Terraformモジュールが組織の標準を一度だけ定義し、CI/CDパイプラインがリモートステート、ロック、ポリシーチェックを伴ってplan、検証、applyを実行します。コンソールでの手動変更はドリフトとして扱い、容認せずに検出します。
高可用性とディザスタリカバリは別々の問題であり、設計も別々です。可用性は、ゾーンをまたぐ冗長化、ヘルスチェック、自動フェイルオーバーで確保します。復旧は、バックアップ、レプリケーション、そして別の場所で再構築するためのリハーサル済みの手順で確保します。目標復旧時間（RTO）と目標復旧時点（RPO）をシステムごとに事業側と取り決めたうえで、それを満たす最も低コストなアーキテクチャを設計します。
基盤は、その状態が見え、認証情報が管理されていて初めて運用できます。インフラとワークロードにOpenTelemetryでメトリクス、ログ、トレースを計装し、リソースの生のしきい値ではなくサービスレベル目標（SLO）に対してアラートを定義します。シークレットはローテーション付きのマネージドストアから発行し、コストはサービス単位・環境単位で追跡して、価格が見える状態でアーキテクチャを判断できるようにします。
優れたインフラの尺度は、プロダクトを開発する人々にどれだけ注意を払わせずに済むかです。チームが変更をマージすれば、コンソールを開くことも専門家を呼び出すこともなく、ビルド、デプロイ、スケール、監視、そして必要であればロールバックまで行われる。そうなったとき、インフラは役割を果たしています。単純になったわけではありません。複雑さが、テストされバージョン管理された自動化の中へ移されたのです。
その状態に到達するには、基盤を、エンジニアをユーザーとするプロダクトとして扱う必要があります。デプロイは手順書ではなくパイプラインです。スケーリングは、人がダッシュボードを見張るのではなく、リクエストの同時実行数やキューの深さといった実際の負荷を反映するシグナルに従います。監視は、ユーザーに影響する目標が危うくなったときにだけアラートを上げます。ノード障害、ゾーン障害、不具合のあるリリースからの復旧は、まず自動化された制御ループであり、ランブックはその次です。
これを行わないコストは、エンジニアリングの時間で支払うことになります。環境を手作業で構成するチームは、ステージングと本番の差異を突き合わせることに工数を費やし、インシデントのたびにシステムの組み立てられ方を調べ直すところから始めることになります。デプロイ、スケーリング、監視、復旧を担う自動化は、その時間をプロダクトに戻します。
アーキテクチャ
エッジ
ネットワーク
ワークロードとデータはプライベートサブネットに配置
コンピュート
データ
プラットフォームサービス
オブザーバビリティ・DR
リストアは想定で済ませず、実際に演習する
可用性のナインを一つ増やすたびに、インフラ費用の面でもアーキテクチャの複雑さの面でも、前の一つより多くのコストがかかります。自動フェイルオーバーを備えた単一リージョン・マルチゾーン構成は、データセンター一つの喪失に耐えることができ、大半の業務システムに適しています。マルチリージョンのアクティブ・パッシブ構成は、リージョン障害への備えが加わる代わりに、レプリケーション遅延とフェイルオーバーの判断という代償を伴います。リージョンをまたぐアクティブ・アクティブ構成はフェイルオーバーの手順をなくしますが、ステートフルなコンポーネントすべてに、同時書き込み、競合解決、距離を隔てた整合性への対処を強います。
正しい設計は、事業側と合意した2つの数値から始まります。システムがどれだけの時間停止してよいか、そして直近のデータをどれだけ失ってよいかです。目標復旧時間が4時間のシステムにアクティブ・アクティブは不要であり、それを構築すれば、単一リージョンの堅牢化に充てられたはずの費用を無駄にします。目標復旧時点がゼロに近い決済システムや取引システムには、リージョン内の同期レプリケーションと、リージョンフェイルオーバー中に処理中のトランザクションがどうなるかについての慎重に検討した方針が必要です。
テストされていない復旧計画は、仮定にすぎません。一度もリストアしたことのないバックアップや、一度もトラフィックを受けたことのないスタンバイリージョンは、実際の状況でしか現れない形で失敗します。そのため私たちは、リストアテストとフェイルオーバー訓練を運用スケジュールに組み込んで設計します。
クラウドのコストは、大部分が設計時に決まります。常時稼働のインスタンスかゼロまでスケールするサービスか、ゾーン間の頻繁な通信かゾーンを意識したルーティングか、ホットストレージかライフサイクルで階層化したストレージか、マネージドサービスか自前運用か。こうした選択が、最初の請求書が届く前に料金の大半を確定させます。事後の最適化で取り戻せるのは、意図をもった設計で回避できたコストの一部にすぎません。
私たちはアーキテクチャ設計の段階で、ワークロードに想定される形状をもとに、性能と並べてコストをモデル化します。定常的かバースト的か、レイテンシに敏感かバッチか、ステートフルかステートレスかです。データ転送、NATゲートウェイのトラフィック、ログの取り込み、使われていない非本番環境は想定外のコストを生みやすい箇所であり、それぞれに確立された設計上の対処があります。基盤の稼働後は、タグ付けによってコストをサービスとチームに配賦し、支出を変えられる人がその支出を見られるようにします。
エンジニアリングの進め方
要件から稼働する基盤まで段階的に進め、各段階でドキュメント、モジュール、環境といったレビュー可能な成果物を作成します。
システムごとに、トラフィックの形状、レイテンシ予算、データ分類、復旧目標、規制上の制約、想定される成長を把握します。これらが、インフラを評価する受け入れ基準になります。
アカウント構造、ネットワークトポロジー、コンピュートモデル、データ配置、障害ドメインのマップを、検討した代替案と不採用の理由とともに作成します。想定負荷とピーク負荷に対するコストはこの段階で見積もります。
ランディングゾーン、ネットワーク、アイデンティティ、共有サービスをTerraformモジュールとして記述し、パイプライン経由で適用します。ガードレールとポリシーチェックは、最初のワークロードが載る前に整えます。
サービスをコンテナ化し、標準のデプロイテンプレートを与え、シークレット、ロギング、メトリクスに接続したうえで、CI/CDでデプロイします。最初のサービスでこの経路を実証し、以降のサービスはそれを再利用します。
スケーリングポリシーに対して負荷テストを実施し、インスタンスやゾーンを停止させてフェイルオーバーを検証し、クリーンな環境にバックアップをリストアします。見つかった問題はWikiのページではなく、コードで修正します。
サービスレベル目標、ユニットコスト、キャパシティの余裕を定期的に見直します。クラスター、ベースイメージ、プロバイダーバージョンのアップグレードは、緊急対応ではなく計画された作業として行います。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
ワークロードはインターネットに直接公開されないプライベートサブネットで稼働し、プライベートエンドポイント経由でマネージドサービスに接続し、静的なキーではなくワークロードアイデンティティで認証します。データは転送中も保存時も暗号化し、分類上必要な場合はカスタマーマネージドキーを使用します。組織レベルのポリシーにより、ストレージの公開、暗号化されていないボリューム、未承認リージョンの利用を防ぎます。
ステートレスなサービスはワークロードのシグナルに基づいて水平にスケールし、その背後でクラスターやインスタンスのキャパシティが自動的にプロビジョニングされます。ステートフルなコンポーネントは、リードレプリカ、パーティショニング、コネクションプーリングによって計画的にスケールさせます。各層がどこで飽和するかは、本番トラフィックで判明する前に負荷テストで把握します。
メトリクス、ログ、トレースをOpenTelemetryで収集し、エッジ、サービス、データ層をまたいでトレースIDで相関付けます。アラートはサービスレベル目標のバーンレートに基づいて発報し、ダッシュボードにはサービスごとの飽和度、エラー率、レイテンシ、コストを表示します。
インフラの変更は、プルリクエストでplanを作成し、ポリシーに照らしてチェックし、パイプラインで適用し、バージョン管理に記録します。アプリケーションのリリースには、ローリング、ブルー/グリーン、カナリアの各戦略を用い、ヘルスやエラー率の悪化時には自動でロールバックします。
基盤は、VPNまたは専用線接続で既存資産と接続し、社内ディレクトリとアイデンティティをフェデレーションし、一貫した認証を備えたAPIゲートウェイを通じてサービスを公開します。ハイブリッド構成や移行のシナリオでは、段階的な切り替えとデータレプリケーションを用い、リスクの高い一度きりの切り替えなしでシステムを移行できるようにします。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
ワークロードと組織に合うプロバイダーです。AWS、Microsoft Azure、Google Cloudはいずれも、本番基盤に必要な基本要素を備えています。重要な違いは、特定のマネージドサービス、リージョンの展開状況、既存のエンタープライズ契約、そしてチームがすでに持っているスキルです。私たちは選定されたプロバイダーに合わせて設計し、コンテナとオープンなインターフェースによってアプリケーション層のポータビリティを保ちます。
はい。まず現行のアーキテクチャ、セキュリティ態勢、コスト構造、運用プラクティスを評価し、そのうえで既存リソースをインポートしながら、資産を段階的にInfrastructure as Codeの管理下に置いていきます。改善はリスクに応じて順序付け、土台を作り直している間も基盤が稼働し続けるようにします。
最初のアーキテクチャの議論から、設計上の制約として扱います。想定負荷とピーク負荷に対するコストを見積もり、ワークロードの形状に合うコンピュートとストレージのモデルを選び、タグ付けによって支出をサービスに配賦します。稼働開始後は、実測した使用率をもとに、ライトサイジング、コミットメントの購入、ライフサイクルポリシーを適用します。
システムごとに合意した目標復旧時間と目標復旧時点、それを満たすバックアップとレプリケーションのアーキテクチャ、別リージョンで基盤を再構築できるインフラコード、そしてテスト済みのランブックです。リストアテストとフェイルオーバー訓練のスケジュールも含まれます。復旧能力は、訓練しなければ低下するためです。
私たちが基盤を運用することも、社内チームに引き継ぐことも、移行期間中にそのチームと並走することもできます。いずれの場合も、成果物には、ほかの誰かが運用するために必要なコード、ドキュメント、ランブックが含まれます。
