アプリケーションのモダナイゼーション
レガシーなモノリスを保守しやすいプラットフォームへ置き換える
作業はアセスメントから始まります。コードとデータベースのレビュー、依存関係のマップ作成、そしてどの機能が、誰に、どのくらいの頻度で使われているかの分析です。これをもとに、コンポーネントを事業価値とリスクで順位付けしたモダナイゼーション計画を作成し、最初のリリースで最も価値の高いコンポーネントに取り組めるようにします。
移行はストラングラーフィグパターンで進めます。Spring BootとNext.jsで構築した新しいサービスが、ルーティング層の背後で機能を1つずつ引き継ぎ、既存システムは残りの機能を引き続き提供します。ユーザーは移行期間を通じて1つのアプリケーションを使い続け、どのコンポーネントも、置き換え先が本番環境で実績を示すまでは停止しません。
コードに問題がなく、プラットフォームだけが古くなっている場合は、代わりにリプラットフォームを行います。アプリケーションをコンテナ化してAWS ECSに移し、独自仕様のミドルウェアを置き換え、データベースをサポート対象のPostgreSQLのバージョンに移行します。
- 順位付けしたモダナイゼーションロードマップを含むアセスメント
- APIゲートウェイまたはリバースプロキシを用いたストラングラーフィグ方式の移行
- Java EEなどのJVMアプリケーションの、Spring Bootとコンテナへのリプラットフォーム
- 切り替えごとの照合レポートを伴うデータ移行
クラウド移行
波ごとに進め、それぞれにロールバック手段を備えたAWSへの移行
移行はサーバーをコピーするだけではありません。まずアカウント構成、ネットワーク、セキュリティを整え、その後ワークロードを波ごとに移行し、各波に独自のロールバック手段を用意します。
まずランディングゾーンから
ネットワークとコンプライアンスの要件に合ったアカウント構成から始めます。本番と非本番を別アカウントに分けたAWS Organizations、ログの一元管理、共有キーに代わるIAMロール、要件に合ったVPC設計です。すべての構成をTerraformで定義し、レビューとバージョン管理を行います。
移行の波
ダウンタイムは合意した時間枠内に収めます。ワークロードを依存関係でグループ化し、重要度の低いものから波ごとに移行します。各波にはテスト計画、切り替えの時間枠、ロールバック手順があります。データベースはレプリケーションで移行します。
ワークロードごとに適切な移行先
アプリケーションサービスはECS上のコンテナ、データベースはマネージドPostgreSQL、イベント駆動のジョブはサーバーレス関数で動かします。リフト＆シフトは、書き直しがまだ正当化されない場合にのみ使い、各選択の理由は文書化します。
すべての波でセキュリティを確保
移行中もデータは保護されます。保存時と転送時の暗号化、マネージドストアでのシークレット管理、最小権限のロール、そしてTLS、WAF、DDoS対策のためのエッジでのCloudflareを、すべての波で適用します。各波の一環としてセキュリティレビューを実施します。
コストの可視化
タグ付けの標準と予算により、各環境・各チームは当初から自らの支出を把握できます。移行後は、実際の利用量が明らかになった時点で、リソースの適正化と予約容量を見直します。
引き渡しまたは運用代行
環境の運用に必要なTerraformのコード、ランブック、トレーニングを貴社チームにお渡しするか、運用代行契約のもとでInterCloudが引き続き運用します。
システム連携
システム間の再入力をなくす連携
企業はERP、人事、CRM、Eコマース、そして部門ごとの多数のツールを運用しており、スタッフがシステム間でデータを再入力していることも少なくありません。当社は手作業による受け渡しを、文書化され、モニタリングされ、貴社が所有する連携に置き換えます。
同期処理の要件には、OpenAPIで記述したREST APIで対応し、非同期のフローにはイベントとキューを使い、遅いシステムや停止したシステムが他を妨げないようにします。レガシーなSOAPサービス、ファイル転送、データベースリンクはアダプターでラップし、他のシステム群が一貫した1つのインターフェースで扱えるようにします。
すべての連携は、何をいつ転送したかを記録し、安全に再試行し、失敗時にはアラートを出します。これにより、データの照合は毎月の作業ではなく、例外時の手順になります。
- バージョン管理され、貴社チームに公開されるRESTとOpenAPIの仕様
- キューと冪等なコンシューマーによるイベント駆動型の連携
- SOAP、SFTP、フラットファイル、データベース直接接続のためのアダプター
- GlowScale、Orbio、および他社のERP、CRM、決済システムとの連携
データ・分析
経営判断のための信頼できるレポーティング
レポーティングのプロジェクトは、たいていデータの品質とタイミングでつまずきます。そのため当社は、まずパイプラインと定義を構築し、ダッシュボードはその後に作成します。
データウェアハウス
1つの中央ストアで、長期的な傾向を比較できます。データウェアハウスはPostgreSQLまたはAWSの分析サービス上で稼働し、各アプリケーションからの定期実行およびイベント駆動のパイプラインでデータを取り込み、履歴を保持します。
共通の定義
財務部門と業務部門が同じ数字に基づいて仕事を進められます。売上、在庫数、サイクルタイムといった各指標には合意された1つの定義があり、文書化され、すべてのレポートに適用されます。
ダッシュボードとレポート
各ロールが必要な数字を確認できます。経営層、管理職、現場スタッフ向けのロール別ダッシュボード、メールによる定期レポート、スプレッドシートでのさらなる分析のためのエクスポートを提供します。
AI活用への備え
アシスタントや予測は、整備され、統制されたデータに依存します。同じデータウェアハウスが、InterCloud AIと、AI・データソリューションで紹介しているモデルにデータを供給します。
ロードマップ
変革ロードマップの典型例
実際には各フェーズは重なり合います。以下の順序は、次のステップを安全に進めるために何が整っている必要があるかを反映しています。
- 1
評価と優先順位付け
アプリケーション、データ、連携の棚卸し、事業部門の責任者へのヒアリング、そして短期的な改善、基盤整備、長期的な置き換えを明確にしたロードマップの作成を行います。
- 2
基盤の構築
AWSランディングゾーン、CI/CDパイプライン、モニタリング、APIゲートウェイを整備します。これらのコンポーネントは以降のすべての取り組みで共有され、通常は最初に目に見える成果物になります。
- 3
波ごとの移行とモダナイゼーション
ワークロードをAWSに移し、レガシーコンポーネントを機能単位で1つずつ置き換え、文書化されたインターフェースでシステムを連携させます。各波は、ユーザーが新しいバージョンで業務を行う状態で完了します。
- 4
データの統合
データウェアハウスへのパイプライン、合意された定義、最初のダッシュボードを提供します。この段階で見つかったデータ品質の問題は、アプリケーションのバックログに追加します。
- 5
運用と改善
環境は運用代行に移行するか、貴社チームに引き渡します。次に何をモダナイズし、廃止し、自動化するかを四半期ごとにレビューします。