機会
長年にわたって開発され、様々なリソースに分散したワークロードを持つサービスプロバイダーにとって、通常は「問題がなければ、修正する必要はない」という考え方が一般的です。しかし、現在のエコシステムがビジネスの成長要件や分野の変化に対応できなくなった場合、すべてのレガシー企業はサービス提供を改善するために新技術を活用することができます。
現在の世界的なクラウドブームの中で、多くのIT企業は単にクラウドに移行すれば問題が解決すると考えています。オンプレミスでホストされている単純なワークロードの場合はそうかもしれませんが、複雑なワークロードの場合は 6R（再ホスト、再プラットフォーム化、廃止、再アーキテクト化、再購入、維持）の組み合わせ. このプロジェクトの中心となる当社のクライアントは、 インド保険規制開発庁（IRDAI）の認可を受けた最大かつ最も信頼される第三者管理者の1つであり、ワークロードのクラウド移行と近代化の可能性を探るためにSourceFuseと提携しました。
主な課題
SourceFuseでは、あらゆるプロジェクトの出発点は、エコシステム全体の詳細な調査プロセスです。物理的な展開、ネットワーク、サードパーティとの相互作用、コンプライアンス要件に加えて、アプリケーションのコードベースの高レベルな調査を行い、ビジネスニーズに応じて6Rに沿って各側面の戦略を特定しました。すべての側面を再アーキテクト化することは可能ですが、時間と費用の主要な制約が最適なソリューションを決定します。
協力的な議論、文書評価、データ収集ツールを通じて実施された包括的かつ詳細な評価に基づき、SourceFuseは顧客の以下の主要な懸念事項を特定しました：
- 仮想マシンのWindowsライセンスは主要なコストであり、ビジネス固有のニーズに貢献していませんでした。
- インフラは固定サイズで24時間365日稼働していました。負荷がないか最小限の場合は損失が発生し、ピーク負荷時にはリソース不足により性能が低下していました。
- アプリケーションのデプロイメントは完全に手動でした。これにより、機能のリリースに多くの時間と労力が費やされ、ビジネスの改善とエンドユーザーの満足度が遅れていました。
- すべてのリソースは手動でセットアップおよび構成されていました。インフラストラクチャスクリプトがないため、破損時の復元が不可能でした。変更は個別に検証され、正確性の手動検証が必要でした。
- リソースのプロビジョニングが混在しており、アプリケーションや環境ごとの分離が不十分でした。
- セキュリティルールはオンプレミスのファイアウォールと密接に結合しており、増加するデータ侵害やハッキング攻撃によってもたらされる成長シナリオに拡張できませんでした。これらのルールはファイアウォールに直接適用され、広範な文書化がされていなかったため、リソースの変更やファイアウォールのクラッシュ時に情報が失われる可能性がありました。
- アプリケーションは完全にモノリシックで、どの側面の変更にも完全なデプロイメントとアプリケーション全体のテストサイクルが必要でした。
- アプリケーションのレガシーな性質により、開発標準への準拠がないため、保守が困難になっていました。
- アプリケーションは添付ディストレージにデータファイルを保存しており、サイズの増加により管理が困難になっていました。
- テストケースは非常に古く、自動化が不足していたため、テストサイクルが長期化していました。これにより、各インスタンスが手動で完全な回帰テストを必要とするため、機能のリリースも遅延していました。
これらの課題に必要な努力とクライアントの優先順位に基づき、SourceFuseはエコシステム全体のTCOを削減しながら上記の課題に対処するための作業計画を設定しました。
解決策
SourceFuseはインフラストラクチャとアプリケーション近代化の側面について、2つの独立したトラックでソリューションを設定しました。
インフラストラクチャの近代化
メインアプリケーションは.NET Frameworkから.NET Coreに移行され、Dockerコンテナ化されてAWS ECSプラットフォームにホスティングされるようになりました。これにより、基盤インフラストラクチャとしてGravitonを搭載したLinuxベースのEC2マシンを使用することで、Windowsライセンスから解放されました。
ECSは負荷に応じてスケーラブルなソリューションを導入することで有効化されました。これにより、低トラフィック時のワークロードコストを最小限に抑え、インスタンス数を自動的に増やすことで、あらゆる量の増加に対応できるようになりました。
全体的なコストを削減するために、プロセッサファミリー、インスタンスサイズ、ストレージボリューム、使用パターン、およびリザーブドインスタンスなど、様々なオプションを検討しました。近代化されていないワークロードは当面そのままにしておきましたが、ECSのバックボーンはGravitonに設定されました。これにより、近代化されたアプリケーションのニーズに準拠しながら、より低コストを実現しました。さらに、非本番環境のワークロードは週末と非稼働時間にシャットダウンするように設定し、追加のコストを節約しました。これらのワークロードは近代化の過程で継続的に進化することが予想されたため、数ヶ月の本番環境での使用を検証するまでリザーブドインスタンスは考慮しませんでした。
近代化されたアプリケーションは、ソース管理とAWS ECSへのシームレスな接続により、AWS CodePipelineで継続的に統合およびデプロイされました。標準的なコンパイルチェックに加えて、Sonarを使用してアプリケーションのコーディング標準をチェックし、Snykを使用して脆弱性チェックを行い、適切に記述されたコードのみがワークフローでさらに処理されるようにしました。環境固有の制御により、開発ビルドはdevelopブランチへのマージごとに継続的に行われる一方で、QAとステージのビルドは制御されたリリースを確実にするために手動でトリガーされるようにしました。
インフラストラクチャの迅速な復旧と検証を可能にするため、完全なセットアップと構成は インフラストラクチャ・アズ・コード（IaC） スクリプトを使用して行われました。これを加速するために、自社開発の アプリケーション再利用可能コンポーネント（ARC） コンポーネントを活用し、より迅速な提供を実現しながら、AWSのWAFや一般的な業界慣行で期待される設計標準にも準拠しました。これらの変更は特定の要件に結び付けることができ、コンプライアンスチームの検証と承認を支援するトレーサビリティマトリックスの確立に役立ちます。
私たちは ランディングゾーン を設定し、インフラストラクチャ全体を特定の環境を表す組織単位のセットとして整理し、共有サービスとセキュリティ管理のための個別の単位も設けました。これにより、リソースの配置に関する明確性が大幅に向上し、より良い財務管理のための専用のコストセンターを持つ個別の請求が可能になりました。
クライアントは物理的なファイアウォールを使用してセキュリティルールを設定していました。組織全体をAWSに移行する際、新しい環境が既存のルールに準拠し、新しい脅威に対応するための追加のセキュリティも必要としていました。SourceFuseは、この重要な要件を中央レベルで管理するための専用の組織単位を設定しました。Security Hubのインスタンスにより、既存の条件がすべて移行されました。さらに、保険固有の要件に準拠する新しいルールを専用のGuardRailsとして設定しました。
アプリケーション近代化
レガシーアプリケーションにより、コードベースは時間とともに複数の問題を継承していました。これは.NET Framework 3.5を使用したMVCのモノリシックアプリケーションでした。コントローラー層は非常に薄く、ほとんどのロジックはSQL Serverのストアドプロシージャに含まれており、クライアント側の処理はjQueryベースのJavaScriptで、多くの場合Ajaxを介してサーバーメソッドを呼び出していました。
これと全体的なアプリケーションのサイジングと複雑さに基づいて、近代化には2つのオプションがありました：
- アプリケーション全体をクライアント側のAngularまたはReactとサーバー側の.NET Core WebAPIの組み合わせとして書き直す。
- アプリケーションのコードベースを整理し、.NET Core Webアプリケーションに移行する。特定の最適化はケースバイケースで実施する。
主な目標がWindowsベースのホスティングのライセンス面を解消することと、プレーンなJavaScriptからAngularへのビジネスロジックの抽出の複雑さを考慮すると、2番目のオプションが最適な選択でした。時間とコストの制約を抑えながら、段階的に機能を提供することが重要であり、これにより技術的な完璧さだけでなく、顧客のニーズに合わせることが確保されました。
コードベースの大部分は.NET Frameworkと.NET Coreの間で直接互換性があり、基盤となるライブラリの変更のみが必要でしたが、すべてのアプリケーションには、そのような統合レベル間で変更される様々なサードパーティライブラリがあります。多くの場合、画像操作のためのWindows GDIコンポーネントとの密接な依存関係があり、他のライブラリはほぼ死滅しており、同じコードベースが現在では書き直しと再購入を必要としています。
主な問題は、統合パートナーからの受信ファイルの解析に広く使用されていたExcelライブラリでした。使用していたコンポーネントには.NET Coreバージョンがなかったため、既存のコードとシームレスに統合できる同等のものを探す必要がありました。これにより、有料およびオープンソースのツールキットを複数確認し、それらの統合を検討し、既存のロジックと照合してコード変更を最小限に抑えるために、複数のスパイクが発生しました。
アプリケーションは入力ファイルを完全に添付ボリュームに保存していたため、年々ストレージサイズが大きく増加していました（保険では7年分のデータが必要）。コードを更新してAWS S3を使用するようにし、安全で確実なストレージを確保しました。これにより、アクティブなファイルとして必要でなくなった場合、将来的にAWS Glacierなどのコールドストレージオプションへの移行も可能になりました。
モジュールを変換している間、クライアントのチームが機能拡張とバグ修正のために古いバージョンで作業を続けているという大きな課題が発生しました。彼らのコードベースと継続的に同期を取り、ほぼ毎月デルタ変更を組み込む必要がありました。これにより同じモジュールに対して繰り返し変更が必要になりましたが、システム全体がリリースされるまでモジュール間の相互依存性があるため、個々のモジュールのリリースは不可能でした。
データベースアクセスが複数の場所から行われていたため、ストアドプロシージャとインラインクエリを1か所にまとめる必要がありました。これは最初、特定のAPIが移行される際に手動で試みられました。これにより、テキスト検索ユーティリティを使用してアプリケーション全体を検索し、作成された定数を含むテキストファイルを生成しました。次に、セッションとビューステートの定数に対して同様の戦略を適用し、既存の場所でもそれらをインラインで置き換えました。これにより、新しい定数を手動で作成してその使用を毎回置き換える時間を節約できただけでなく、コードレビューの労力の削減と一貫性の向上にもつながりました。
SourceFuseのアプローチ
何かを消費できるのは、機能要件と非機能要件の両方についてテストされた場合のみです。近代化主導の移行アプローチでは、アプリケーションだけでなく、インフラストラクチャの側面もテストする必要があります。
仮想マシンについては、AWS EC2への移行後、クライアントのITチームが構成が intact であり、ドメインコントローラーで定義されたポリシーと同期できることを確認しました。アプリケーションチームは、いくつかのサンプルワークフローを実行してデータベースとサードパーティの接続が適切に機能していることを確認することで、アプリケーション設定を検証しました。セキュリティ設定は、不正なリクエストを実行してファイアウォールがそれらをブロックし、全体的なパフォーマンスに影響を与えることなく正当なトラフィックを許可することを確認するクラッシュテストを実行することで検証されました。
アプリケーション面では、レガシーアプリケーションであるため、文書化されたテストケースのほとんどが非常に古く、エッジケースは適用できませんでした。クライアントと各テストケースを明示的に議論し、様々なテストシナリオに合わせて適切なテストデータを設計しました。これは非常に時間がかかったため、基礎となるコントローラーメソッドの自動テストを設定することを決定しました。これが確立されると、回帰変更を非常に迅速に検証でき、フロントエンド依存のワークフローにのみ焦点を当てる必要がありました。
災害復旧
すべてのビジネスモデルは自然災害に対して回復力を持つ必要があり、したがって地理的地域をまたがってホスティングする必要があります。政府のコンプライアンス要件により、インドで発生する保険データは国境を越えて外に出ることができません。ムンバイが当初インドで利用可能な唯一の地域だったため、すべてのリソースはそこにのみ設定されていました。当初の計画ではムンバイ地域内で複数のアベイラビリティゾーンを持つ予定でしたが、クライアントはガバナンス委員会の承認を確実にするために物理的な地理的分離も必要としていました。幸いなことに、プロジェクトが開始されたとき、AWSはハイデラバード地域で別のリージョンを開始したため、私たちは二次リージョンでのサービスの可用性を継続的に追跡しました。
新しい地域であるため、サービスは実際の可用性と部分的な機能の可用性の両方で不足していますが、すべてのサービスがDR地域に依存しないようにリソースベースの災害復旧（DR）を持つことが決定されました。また、データベースなど、DR地域でライブで実行されるリソースは一部のみにすることを望んでいました。
私たちは AWS災害復旧サービス（DRS） を設定して、添付ボリュームを持つEC2をDR地域のハイデラバードと同期させました。IaCスクリプトはすべてのリソースの再作成に使用されるため、フォールバックは問題になりません。ECS上のプライマリアプリケーションについては、ハイデラバード地域でゼロインスタンスで設定されました。DRがトリガーされる場合、DNSレコードを新しい地域を指すように更新し、インスタンスを増やすことができます。フォールバックの場合、CI/CD構成によってムンバイ地域に再デプロイされます。
結果
どれだけ経験があっても、すべてのプロジェクトは新しいアイデアの機会を提供し、新しい教訓を教えてくれます。このプロジェクトは、インフラストラクチャとアプリケーションの改善からデリバリーを切り離しながら、顧客が時間と予算の範囲内で可能な限り最高のものを得られるようにする方法について、チーム全体にとって素晴らしい学習経験となりました。
- 最初のスプリントでアプリケーションフレームワークを設定し、最初のモジュールに対して検証することで、私たちは正しい道を進んでいるという確信を得ました。
- 可能な限り多くを自動化することは、最初は時間がかかりますが、将来大きな見返りをもたらします。私たちはCI/CDパイプラインを通じてコードのデプロイメントを自動化しただけでなく、インフラストラクチャコードも同じトレーサビリティに従い、アプリケーションのニーズに応じて進化し、 アプリケーションと 共にデプロイされることを確実にしました。
- 多くの場合、機能を実装しましたが、要件を満たさないか単に完全に機能しないために却下されましたが、私たちは手順と却下の理由を文書化することを確実に行いました。これにより、将来のイニシアチブのための優れた知識ベースを構築することができました。
- 近代化は一段階のプロセスではなく、旅路です。私たちはアプリケーションのアーティファクトをモジュールごとに整理し、ニーズに基づいて将来の改善の候補となるようにしました。
- 将来の拡張をサポートするための技術的負債登録を確立します。実装は完璧ではなく、すべてのニーズに適合することはできないため、技術選択に基づいていくつかの負債が発生します。これは.NETのさらなる改善を検討する際、または別のAWSの拡張を検討する際に将来対処することができます。
顧客について
1995年に設立され、ハイデラバードに本社を置くこの事例研究の中心となる顧客は、2002年にIRDAIによってライセンスを付与され、現在インドで最大かつ高い評価を受けているIRDAIライセンス取得第三者管理者（TPA）の1つです。 インド全土で55以上の拠点と25の州に展開し、個人顧客、企業顧客、州/中央政府が後援する健康保険制度にサービスを提供し、会員に幅広い関連ヘルスケアとウェルネスサービスを提供しています。着実に増加する顧客数は、卓越したサービスを提供するための一貫性と努力の証です。
