環境:4層構成のデュアルサイトアーキテクチャ

移行前、Software Projectsのチームは、耐障害性を考慮して規模を分けた2つのIBM Cloudリージョン(大規模なプライマリサイトと小規模なセカンダリサイト)で、明確に定義された単一のアーキテクチャを運用していました。各サイトは同じ4層構成を採用していました:

• ロードバランシング:本番、開発、トラッキングのトラフィックをそれぞれ処理する少数のHAProxyインスタンス群。
• アプリケーション:Webサーバーとトラッキングサーバー、スケジュールジョブ実行サーバー、コード品質管理(SonarQube)サーバー、VPNゲートウェイ(プライマリサイトのみ)。
• コンテナオーケストレーション:自己管理型のDocker Swarmクラスター。プライマリサイトでは本番用と開発用を分離して運用し、セカンダリサイトでは単一クラスターで運用。
• データ:MySQLのプライマリ/レプリカ構成と3ノードのCassandraクラスター。両サイト間でレプリケーション。

DoiTの移行計画では、このトポロジーをus-east-1の単一AWS VPCへ1:1で忠実にリフト&シフトすることとしました。24ノードと16ノードという構成規模はそのままに、地理的に独立した2つのIBM Cloudリージョンではなく、1つのAWSリージョン内の複数のアベイラビリティゾーンに分散配置する形です。以下の表は、各層の構成が変更なくそのまま引き継がれたことを示しています:

これらのノード数はカットオーバーの前後で一切変わりませんでした。同じ24ノードと16ノードが、同じ層別構成のまま、単に移設されただけです。この徹底ぶりが大きな意味を持ちました。Software Projectsのチームは、既に熟知している環境と全く同じように動作するAWS環境を引き継ぐことができ、その一方でDoiTは、2つのデータセンターリージョンを複数のアベイラビリティゾーンにまたがる単一のAWSリージョンに集約することで、インフラの複雑さを一段階取り除いたのです。また、AWS上で環境が安定した後に自己管理型のDocker Swarmクラスターを廃止し、マネージドコンテナプラットフォームへ移行するというロードマップが既にあったため、Modernizeフェーズへのスムーズな布石にもなりました。

アプローチ:AWS MAPをエンドツーエンドで提供

DoiTは、AWS MAPの3フェーズを通してこの支援を推進しました。各フェーズが次のフェーズの技術的・財務的基盤を築く形で、DoiTのForward Deployment Engineeringチームがエンドツーエンドで提供しました。

1. Assess:根拠のある移行予算の策定

ワークロードを移す前に、Software Projectsのチームは、AWSのストレージとコンピューティングにかかるコストをサービス単位で明確に把握する必要がありました。DoiTはEBSとEFSを対象に、ボリュームタイプやストレージクラスごとの月額ストレージ、IOPS、スループットのコストをモデル化した詳細なコスト内訳を作成し、Software Projectsが移行ロードマップの短期・中期の支出を予測できるようにしました。また、Software Projectsのデータベースコンピューティングに対する割引戦略についても検討を進め、DoiT Flexsave(前払いのcommitments不要でCompute Savings Plans相当の割引が受けられる仕組み)と、スタンダードおよびコンバーティブルのリザーブドインスタンス価格を比較。将来的なマネージドデータベースサービスへの移行の可能性も踏まえ、それぞれのトレードオフを説明しました。

2. Mobilize:クラウド間接続の課題を解決

IBM CloudとAWS間の接続は移行全体のクリティカルパスであり、既製の解決策は存在しませんでした。DoiTは、AWS Direct Connect、IBM Direct Linkの専用回線、仮想ルーターアプライアンス、軽量なメッシュVPNといった選択肢を、コスト、安定性、構築の複雑さの観点から体系的に評価しました:

• AWS Direct ConnectとIBM Direct Link Dedicatedを専用回線オプションとして評価(BGP、IPレンジ、課金上の制約を含む)。
• 長期的な選択肢を検討する間の、迅速かつコストゼロのフォールバックとして、メッシュVPNオーバーレイを試験導入。
• IBM側での仮想ルーターアプライアンスの導入とチューニングを支援(VLANルーティングの挙動の調整や、IBMサポートと連携したレイヤー2のトラブルシューティングを含む)。
• より柔軟なネットワーク構成を実現するため、IBM Classic InfrastructureからIBM VPCへの移行を支援し、IBM VPCとAWS VPC間にIPSecサイト間VPNを構築。
• IBM ClassicとAWS間のサブネット重複とルーティングの欠落を特定・解決。重複しない専用IPレンジの割り当てと静的ルートの調整により、3つの環境間の双方向通信をついに実現。

その結果、IBM Classic Infrastructure、IBM VPC、AWSを結ぶ、安定した検証済みのプライベートネットワーク経路が確立されました。これにより、Software Projectsのチームは、IBM上で稼働し続けるシステムへの接続を失うことなく、自らのスケジュールでワークロードを移行できる基盤を手に入れました。

移行期間中も本番環境の健全性を維持

移行期間中、DoiTはAWS側でも迅速な運用支援を提供しました。あるケースでは、EC2インスタンスが予期せずSSM接続を失い、SSHによるフォールバックも利用できない状態に陥りました。DoiTはコンソール出力の診断により根本原因(ルートボリュームのディスク容量枯渇によりSSMエージェントが起動できなかったこと)を特定し、ボリューム拡張とファイルシステムのリサイズという段階的な復旧手順を提示。さらに、再発防止のためCloudWatchによるディスク使用率アラームとSNS通知を先回りで設定し、特に本番システムを同種の障害から保護することに重点を置きました。

3. Modernize:コンテナ化と継続的なコスト最適化

移行の完了に伴い、支援はModernizeフェーズへと進みました。Software Projectsの本番および開発スタックは、依然として自己管理型のDocker Swarmクラスター上で稼働していました。機能はしているものの、マネージャーとワーカーへ手動でパッチを適用するという運用負荷を抱えていました。DoiTは現在、Mobilizeフェーズで確立したマルチAZ構成の統合VPC基盤を、ゼロからの再設計なしにそのまま活用し、SwarmクラスターをAWSのマネージドコンテナプラットフォーム(Amazon EKS)へ置き換える取り組みを支援しています。

同じモダナイゼーションの一環として、DoiTは環境の進化に合わせてクラウド支出の規律も維持しています。DCI Insightsを活用してSoftware ProjectsのAWS DetectiveとGuardDutyの構成をレビューしたところ、セキュリティツールのコストが全体支出のかなりの割合を占めるまでに増大しており、その主因は提供されるセキュリティ価値ではなく、大量のフローログの取り込みであることが判明しました。DoiTは、どの高重要度の検出タイプがどのデータソースに依存するかを含めてトレードオフを定量化し、最も価値の高い検出を失うことなくセキュリティカバレッジをライトサイジングするための、明確でエビデンスに基づいた選択肢を提示しました。この規律あるエビデンス重視のアプローチは、コンテナ化の取り組みにもそのまま引き継がれています。事後に最適化するのではなく、最初から適正な規模で構築するのです。

ソリューション:DoiT Cloud Intelligence(DCI)の活用

ハンズオンのエンジニアリング支援と並行して、Software Projectsは取り組み全体を通じてDoiT Cloud Intelligence(DCI)の複数の機能を活用しました。経験豊富なデリバリーチームと、自社のAWS環境をセルフサービスで可視化する仕組みの組み合わせです:

最後の2つの機能は日々の運用で活躍しています。Software Projectsのチームがコンテナへのモダナイゼーションを進める中、DCI AWS IntelligenceとDCI Datadog Insightsにより、月次請求書で問題が発覚するのを待つことなく、クラウドとオブザーバビリティの総支出を継続的に可視化できています。

• 過去の自己管理での試みが一方向でしか機能しなかった中、IBM Cloud InfrastructureとAWS間で初めて機能するプライベートネットワーク経路を確立。
• ロードバランシング、アプリケーション、オーケストレーション、データからなる4層トポロジー全体を含む全40台のサーバーを、層ごとの構成を変えることなくAWSへ移行。チームは初日から慣れ親しんだ環境をそのまま引き継ぐことが可能に。
• 地理的に離れた2つのIBM Cloudリージョンを、複数のアベイラビリティゾーンにまたがる単一のAWS VPCに統合。デュアルサイト設計の耐障害性を犠牲にすることなく、ネットワークと運用の構成を簡素化。
• 移行に先立ち、ストレージとコンピューティングに関する粒度の高い、根拠のあるコストモデルをSoftware Projectsに提供し、移行中の予算面での想定外を削減。
• 本番環境に影響を及ぼしたSSM障害を明確な根本原因とともに解決し、同様の障害を次回はより早期に検知できるプロアクティブな監視体制を整備。
• AWS MAPの3フェーズ(Assess、Mobilize、Modernize)すべてを一貫した単一の支援として提供し、フェーズの区切りごとにリセットすることなく移行のコンテキストを継承。
• セキュリティとコストの体制を次フェーズ開始前に適正化した上で、自己管理型Docker Swarmクラスターからマネージドコンテナプラットフォームへ移行できる状態を構築。
• インフラのマッピングにはDCI Cloud Diagrams、クラウドとオブザーバビリティ支出の継続的な追跡にはDCI AWS IntelligenceとDCI Datadog Insightsという、自社環境をセルフサービスで可視化できる仕組みを提供。

Software ProjectsのAWS環境は、いま次のモダナイゼーションフェーズに向けた安定した基盤となっています。DoiTは、初期アセスメントから完全に接続された本番稼働可能なAWS環境の実現まで移行を支えてきた、技術デリバリーと継続的なコスト規律の組み合わせをそのままに、ワークロードのコンテナ化を進める同社との協業を継続しています。

Software Projectsは、本番環境と非本番環境が混在する環境を運用するソフトウェアサービス企業で、従来はIBM Cloud Infrastructure上でホスティングを行っていました。より広範なクラウド戦略の一環として、同社はAWS Migration Acceleration Program(MAP)のもとでワークロードをAWSへ移行するためDoiTと契約。DoiTがAssess、Mobilize、ModernizeのMAP全3フェーズを提供しました。