環境:4層構成・2サイトのアーキテクチャ

移行前、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(前払いコミットメント不要でCompute Savings Plan相当の割引が得られるサービス)をスタンダードおよびコンバーティブルのリザーブドインスタンス料金と比較し、将来的なマネージドデータベースサービスへの移行の可能性を踏まえて、それぞれのトレードオフを説明しました。

2. Mobilize:クロスクラウド接続の解決

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

• 専用回線の選択肢として、AWS Direct ConnectとIBM Direct Link Dedicated(BGP、IPレンジ、課金上の制約を含む)を評価。
• 長期的な選択肢を検討する間の、迅速でコストのかからないフォールバックとしてメッシュVPNオーバーレイを試験導入。
• IBM側での仮想ルーターアプライアンスの導入とチューニングをSoftware Projectsに指南(VLANルーティングの挙動や、IBMサポートと連携したレイヤー2のトラブルシューティングを含む)。
• より柔軟なネットワーキングを実現するため、Software Projectsの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エージェントが起動できなくなっていたのです。DoiTは段階的な修復計画(ボリューム拡張とファイルシステムのリサイズ)を提示するとともに、再発防止のためCloudWatchのディスク使用率アラームとSNS通知をプロアクティブに設定し、特に本番システムが同じ障害モードに陥らないよう重点的に対策しました。

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

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

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

ソリューション: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に統合。2サイト設計の耐障害性を犠牲にすることなく、ネットワークと運用の複雑さを簡素化しました。
• 移行に先立ち、ストレージとコンピューティングに関するきめ細かく根拠あるコストモデルをSoftware Projectsに提供し、移行時の予算面での想定外を減らしました。
• 本番環境に影響するSSM障害を明確な根本原因の特定とともに解決し、次回は同じ障害をより早期に検知できるプロアクティブな監視体制をSoftware Projectsに残しました。
• Assess、Mobilize、ModernizeというAWS MAPの3フェーズすべてを1つの継続的なエンゲージメントとして提供し、フェーズの境界ごとにリセットすることなく移行のコンテキストを引き継ぎました。
• 次のフェーズが始まる前にセキュリティとコストの体制をあらかじめライトサイジングした状態で、自己管理型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フェーズを提供しました。