評価

コンテナ化の対象となるアプリケーションを評価して、すべての依存関係とリスクを明らかにすることができます。また、評価によって、アプリケーションをモダナイゼーションおよび移行の優先バケットに分類することができます。

評価段階では、以下の主要分野に焦点を当てます。

• コンテナ化のオペレーティングシステムの依存関係 – AWS App2Container などの自動コンテナ化ツールには、コンテナ化のアプリケーションフレームワークとオペレーティングシステムにいくつかの制限があります。サポートされているアプリケーションの詳細については、「App2Container のドキュメント」を参照してください。

• 規制コンプライアンス — デプロイした後に事後対応して規制を緩和するよりも、ターゲット環境にデプロイする前に、コンテナ化されたアプリケーションがすべての規制に準拠していることを確認する方が効率的です。イメージ内の脆弱性、コンテナ間の不正通信、コンテナとデータへのアクセスコントロール、悪意のあるアクティビティを防止する自動スキャンをチェックします。

• ディザスタリカバリ (DR) ソリューション — 各アプリケーションには、ダウンタイムに関する独自のサービスレベルアグリーメント (SLA) があります。コンテナクラスターの分散を計画するときは、アプリケーションの目標復旧時点 (RPO) と目標復旧時間 (RTO) を念頭に置いてください。App2Container はデフォルトで、アプリケーションを複数のアベイラビリティーゾーンにデプロイします。

• データストレージ — コンテナはステートレスとして使用するのが最適です。ステートフルコンテナの場合、データはコンテナの外部に保存する必要があります。コンテナがサービスを停止した場合でも、データを失うことなく、イメージおよびアタッチされた外部ボリュームを使用して新しいコンテナを起動できます。

• 設定とシークレットの管理 — ターゲット環境のパラメータストアまたはシークレットストアを使用して、設定とシークレットをコンテナから保存・取得することができます。シークレットには、関連するコンテナのみがアクセスできるようにすることが重要です。設定とシークレットに関するすべての操作はログに記録する必要があります。コンテナとシークレットストアとの間の通信チャネルは安全である必要があります。

• ログ管理 — 各コンテナで生成されたログは、監査のため、コンテナの外部にあるログ管理サービスに送信されます。アプリケーションは複数のサービスとプロセスで構成され、それぞれが異なるコンテナに存在するため、各コンテナのログには一意の ID が必要です。

• 構築とデプロイのプロセス — ほとんどの企業では、アプリケーションや機能をリリースするために、構築とデプロイに何らかのプロセスを採用しています。コンテナ化の利点を生かすには、CI/CD パイプラインを使用してアプリケーションの構築とデプロイを自動化する必要があります。パイプラインには、インフラストラクチャのプロビジョニングと廃止をワンクリックで実行、迅速かつエラーのないデプロイ、自動化、新機能のリリースまでの時間の短縮などの利点があります。

• アップストリームとダウンストリームのアプリケーション — 依存するすべてのアプリケーションをバッチ処理でコンテナ化して移行することをお勧めします。それが不可能なシナリオでは、コンテナ化されたアプリケーションからアップストリームおよびダウンストリームのアプリケーションへの通信チャネルを安全に開く必要があります。このチャネルがサポートする帯域幅がアプリケーションの機能を妨げることがないようにします。

• ライセンスの依存関係 — アプリケーションの複数のインスタンスがコンテナ内で実行されるため、コストが高くなる可能性があります。コンテナにソフトウェアをデプロイするための契約と適格性を確認してください。コンテナで消費されるソフトウェアの計測に使用されるツールを把握してください。

• アプリケーションサーバーまたはワーカーマシンでのコンテナ化の実現性 — コンテナ化プロセスでは、ディスク容量、計算能力、メモリなど、サーバー上の追加リソースが消費されます。アプリケーションサーバーを分析して、コンテナー化プロセスをサポートできることを確認する必要があります。サポートできない場合は、必要なリソースを備えていて、アプリケーションサーバーと通信できるワーカーマシンを使用してください。

• コンテナに関するデベロッパースキルと本番稼働サポート — 現在のアプリケーションチームは、コンテナ化技術のスキルを高める必要があります。チームはプロセス中の問題をトラブルシューティングし、必要に応じて設定を微調整し、コンテナにデプロイされたアプリケーションをサポートできる必要があります。

App2Container を使用すると、スタンドアロンの JBoss、Apache Tomcat、IBM WebSphere、Oracle WebLogic など、Linux 上で動作する Java アプリケーションをコンテナ化できます。また、App2Container を使用して Spring Boot などの汎用 Java アプリケーションをコンテナ化することもできます。アプリケーションのコンテナ化は、マイクロサービスや分散アプリケーションで動作します。すべての Java アプリケーションは App2Container を使用してモダナイズできますが、以下の基準を参考にしてモダナイズする適切なアプリケーションを選択すると、移行を迅速に行うことができます。

• 1 つのバイナリとしてパッケージ化されているアプリケーションは、コンテナ化を容易に行うことができます。また、Java アプリケーションは Java ランタイム環境 (JRE) でコンテナ化できます。各コンテナは、そのコンテナに必要な特定の JRE を使用することができます。

• コンテナへのモダナイゼーションには、ステートレスアプリケーションが適しています。これらのアプリケーションは最小限の情報をローカルに保存し、ほとんどのデータを永続的なデータストアに保存します。

• 継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインを使用してリリースされているアプリケーションは、コンテナ化に適しています。各アプリケーションをコンテナ化し、Amazon ECS や Amazon EKS などのコンテナオーケストレーションプラットフォームを導入します。アプリケーションは App2Container によって自動的に処理されます。

ほとんどのエンタープライズアプリケーションは、認証、永続的なデータストア、キャッシュ、非同期通信、ログ記録、通知などのさまざまなサービスと統合されています。コンテナ化を成功させるために、コンテナ化されたアプリケーションは、既存のすべての統合ポイントを使用してオンプレミスでテストする必要があります。移行の準備ができたら AWS、すべての適切な統合ポイントとデータストレージを移行する必要があります AWS。アプリケーションコンテナを AWSにデプロイする前に、設定に必要な更新を行う必要があります。

ファイルシステムに保存されているデータは、ユースケースに対応する AWS さまざまなツールを使用して に移行できます。Redis などのキャッシュに保存されているデータは、Amazon ElastiCache に移行できます。データベースに保存されているデータは、データベース独自のネイティブツールまたは AWS Database Migration Service () を使用して移行できますAWS DMS。 には、ソースデータストアからカットオーバーまで継続的な変更をレプリケートする変更データキャプチャ (CDC) オプション AWS DMS も用意されています。

AWS は、Amazon CloudWatch と呼ばれる独自のモニタリングおよび運用データログ記録および視覚化サービスを提供します。CloudWatch エージェントは、このサービスを使用するアプリケーションと一緒にコンテナに入れることができます。

App2Container は、アプリケーションのランタイム環境で動作し、ソースコードを必要としないため、ソースコードが利用できない、またはメンテナンスできない組織の場合、コンテナ化に最適なツールです。