オンプレミスからAWSへ12 factor appsを意識したクラウドネイティブなWebシステム移行を成功させるためのポイント
前提
本記事の目的
オンプレミスからAWSへのWebシステム移行のニーズは2024年現在も非常に多くあります。その中でただAWSに移行するのではなくクラウドネイティブを志向してより品質の高いWebシステムの実現を求めるケースが増えています。
クラウドネイティブなWebシステムを実現するにあたって、The Tweleve-Factor App（以下12 factor app）の観点は非常に重要です。
AWSブログでも以下のような解説記事があります。
今回はこの記事に登場するAmazon ECS/AWS Fargateを用いた構成について特にオンプレミスからの移行を実現する際にポイントとなる点を解説致します。
12 factor appとは
12 factor appとはモダンなWebプリケーションのあるべき姿を12のベストプラクティスにまとめた方法論のことです。
具体的な内容については以下を参照ください。
ここで記載されている12のプラクティスはいずれも今回の記事の対象にするコンテナアプリケーションと親和性の高いものです。
更にAWSの各種サービスを組み合わせることによって12のプラクティスを効率的に実現することができます。
これによって仮想サーバを大量に使って構成を組むよりも品質の高いWebシステムを構築しやすくなります。
クラウドネイティブなWebシステム移行を成功させるポイント
オンプレミスからAWSへ、12 factor appを意識してWebシステム移行を成功させるポイントとして以下6点があげられます。
- 要件を"現行踏襲"で終わらせない
- システム開発においてアプリ担当・インフラ担当という区分に固執しない
- 現行システムで行っている複雑な構成・運用はその目的を再点検する
- 性能予測はほどほどにしておく
- コストの意識を転換して、AWS利用料と保守運用作業工数のバランスをとる
- AWSならではの機能を有効活用する
1. 要件を”現行踏襲”で終わらせない
これはオンプレミスからAWSへの移行案件だけでなく更改案件全般に言えることですし、多くの方がご認識されている通りだと思いますが、更改案件において最も重要だと思いますのであえて記載します。
要件定義を”現行踏襲”という言葉で終わらせることは厳禁です。
現行を踏襲するというのが何がどうなることを指すのか明確にすることが必要ですし、そのうえで、特にオンプレミスからAWSに移行する際には各種業務処理やオンプレミスの各機器（サーバやNW機器、ストレージ等）が行っている役割を明確にしてアーキテクチャを考えることが必要です。
2. システム開発においてアプリケーション担当・インフラ担当という区分に固執しない
AWSでクラウドネイティブなWebシステムを作ろうとするとオンプレミスの頃と比べて「このタスクはアプリケーション担当・インフラ担当どちらがやるべきなのか」の色分けを明確に行うことが難しくなります。
例えばAmazon ECSとAWS Fargateを用いてコンテナを実行する場合、以下のようなタスクが必要になってきます。
- ECSクラスタの作成
- ECSサービスの作成
- ECSタスク定義の作成
- ECRリポジトリの作成
- ECSタスクのログ出力用Cloudwatch Logsロググループの作成
- ECSタスクが利用するためのIAM（ECS Task Role及びECS Task Execution Role）の作成
- ECSサービスで指定するためのNW環境（VPC/Subnet/Security Groups）の作成
- dockerfileの作成
- コンテナイメージのビルド
- ECRリポジトリへのコンテナイメージのPUSH
- ECSタスクの立ち上げ
上記のタスクの各項目をアプリケーション担当者・インフラ担当者が協力して行うことが必要な他、特にECSタスク定義等はアプリケーション・インフラどちらにも関係する内容が存在するためお互いに協力しながら作成することが効率的な場合もあります。
例えば保守運用を見据えてIaCで環境を一括管理するために環境へのデプロイ作業自体はインフラ担当者のみが実施するという場合でもそのための情報はアプリケーション担当者と一緒になって検討・作成することや、デプロイ時に問題が発生した場合には共同で対処することがスムーズな環境構築には欠かせません。
アプリケーション担当者・インフラ担当者がともに協力すべきというのはオンプレかAWSかを問わず必要なことですが、特にクラウドネイティブを志向する際にはその境界はあいまいなものでその線引きをし始めると抜け漏れは必ず出てきます。誰の役割かを意識しすぎることなくお互いに一歩踏み込んで対応を行うことが成功のポイントになると考えています。
なお、最近ではAWS CDKなどを用いることでアプリケーション担当者のみでも簡単に環境構築ができるのでインフラ担当は不要なのでは無いか、という意見を聞くこともありますが、この点に関して保守運用フェーズまで考慮してアプリケーション担当者のみで対応し続けられるかというポイントで検討すべきだと考えています。
アプリケーション担当者のみでAWS CDKを使って適切なインフラ環境を維持し続けられる見込みがあればそれも選択肢になると思いますが、私の経験上は現実的に本番商用環境でそこまでできるケースは2024年4月の現時点ではあまり多くないのではないかという感触を持っています。
3. 現行システムで行っている複雑な構成・運用はその目的を再点検する
これは1点目の現行踏襲で済ませない、という点にも関連しますがオンプレミスで5～10年と長くシステムを稼働させているとその中で発生した障害や問題への対応として複雑なシステム構成/設定や手動運用が出来上がっているケースがあります。
よくあるものとして、例えばロードバランサやWebサーバ等で複雑な条件に該当した際に処理（リダイレクト/リクエスト内容の書き換え等）を行うケースや、定期的に担当者がサーバからログを取得して独自のツールにかけてセキュリティ面等のチェックを行うケースなどがあげられます。
これらについて全てをそのままAWS環境で実現する前提で考えるのではなく達成すべき本質的な目的に立ち返って扱いを決めることが必要です。
例えばセキュリティ対策で行っている作業があるのであればそれによって防ぎたい具体的なセキュリティリスクが何なのかを特定し、それに対してAWSのセキュリティ系のサービスで防ぐことはできないのか、仮に作りこみが必要とした場合でもAWSのサービスを組み合わせることでより効率的な仕組みにできないのか、といった検討を行うべきだと考えています。
その理由は1点目にはプロジェクトリスクを低減させるためです。私はこれまでオンプレからAWSへ多くの更改案件を行ってきましたが、想定外の問題が起きやすいのはやはりオンプレミスで行っている独自の仕組みをそのままAWSに持ってきたいというケースです。オンプレミスからクラウドネイティブなAWS環境にする時点で違いが出てくるのは不可避ですので、従来の仕組みにとらわれることなく達成すべき目的を起点に解決策を検討すべきです。
それから理由の2点目として、特殊な仕組みを受け入れることでクラウドネイティブな構成を採用することが難しくなる可能性があるためです。例えば常に特定のサーバが存在し続けることを前提とした仕組みの場合12 factor appでいう廃棄容易性(Disposability)に反することになりますし、冗長構成を組んでいるサーバのうちの1台だけが特殊な処理を行う作りになっていると12 factor appの中の並行性（Concurrency）にも反してしまいます。こういった点を考慮せずにそのままAWSに移行すると構成の形はクラウドネイティブなように見えるものの、実態はクラウドネイティブの恩恵をあずかることのできない残念なシステムになってしまいます。
更改前のシステムで行っている各処理や構成・運用については何かしらの背景がある場合が多いのでそれらに関して十分理解することがまずは必要です。そのうえで、そもそもの背景が何で、どういうことが達成できれば良しとなるのかを明確にしてクラウドネイティブな構成の中でどう実現すべきか検討し採用していくということを意識することが必要だと考えます。
また、これを実現するためには現行システムの保守運用を担当している人たちの協力も欠かすことができません。
具体的に現行システムにどういう特殊要因が存在し、それに対してどのような手立てをなぜ採用したのか、といった点について最も理解しているのはそのシステムを保守運用している人たちであることが多いです。そのためプロジェクトの中ではその人たちも巻き込んで整理・検討を行っていくことが重要だと考えます。
4. 性能予測はほどほどにしておく
更改案件では現行システム側の実績が存在することや、今後システムで必要となる処理量の目途がつきやすいことから、コンテナ台数/スペックや最大で処理できるトランザクション量予測など各種性能面に関する予測を案件の初期段階で行いたいというニーズが多く出てきます。
しかし、特に現行システム（オンプレミス）を仮想サーバで稼働させていた場合コンテナに変わることで必要なリソースは変動して予測は難しいですし、コンテナにすることでスピーディなスケールアウトに対応できるようになるため予測する意味もオンプレミスのシステムと比べると少ないです。
その他データベースについてもAmazon Auroraを採用してスケーリング性能を確保することで初期時点での厳密な性能予測は必要性が薄くなります。
また、「この構成でシステムを稼働させた場合最大どの程度まで処理に耐えられるか」という予測をしたくなる場面もあるかと思いますが、そちらについても机上の計算だけで算出するだけだと意味のある数字にすることは難しいと考えています。
もちろん今後システムを維持するにあたって予めコストの見通しを立てたい、といった必要性から性能予測を行うことが求められるケースはあるかと思いますが、そこは大外れしない程度の概算にとどめてあまりそこに時間をかけることなく、以下3点を意識することが重要だと考えます。
- 性能テストの中で性能チューニングを行う前提として必要な観点を漏らさずに実施する
- 保守運用フェーズで構成追加など必要な時に性能テストを実施できるよう本番同等の環境を保有する(12 factor appでいう開発/本番一致 (Dev/prod parity) )
- 保守運用の中で性能実績値に対する監視や定期的なリソース状況評価を実施する
この観点を意識することによって特に案件の初期段階（要件定義・設計）において性能予測に時間を割くことなく、優先度高く取り組むべき検討事項に注力することができるようになるため、プロジェクトの成功につながると考えています。
5. コストの意識を転換して、AWS利用料と保守運用作業工数のバランスをとる
オンプレミスからAWSへの更改案件ではオンプレミスの機器・ソフトウェアにかかっていた費用とAWS利用料をシンプルに比較するケースがみられます。
しかしAWSをクラウドネイティブで有効に活用するにあたっては単純に機器・ソフトウェアの代替として扱うのではなく、AWSに従来の保守運用に該当する一部をオフロードしたり、オンプレミスの際に人手で行っていた作業を自動化したり効率化することが想定されます。そのため、単純に試算した結果AWS利用料が高く見えるから特定のサービスを使わない、という選択をするのではなくそのサービスで実現されていることを保守運用作業の中で行ったとしたらどのぐらい大変なことなのか、ということまでイメージしたうえで扱いを決定すべきであると考えます。
特にAWS上でクラウドネイティブな構成を実現した場合、監視やログ管理、バックアップ/リストア、アプリケーションバージョンアップ等保守運用の中で必要な様々な機能をAWSのサービス群と組み合わせてスムーズに行うことが可能です。それら多くのAWSサービスを活用した際に算出されるAWS利用料には元々オンプレミスで保守運用担当者が行っていた手動作業が多く含まれています。そういった意味でもコストの考え方をオンプレミスの頃から転換することが必要です。
6. AWSならではの機能を有効活用する
クラウドネイティブなシステム構成で成功するためには業務処理を直接行う部分だけではなく、保守運用に関する部分についてもAWSサービスを活用していくことが有用です。
その中でも12 factor appの観点からは以下2つを意識することが重要と考えます。
- AWS Code系サービスによるCICDの実装(12 factor appのビルド、リリース、実行(Build, release and run))
- AWS X-Rayによるオブザーバビリティの確保(12 factor appの並行性(Concurrency)と廃棄容易性(Disposability))
1点目について、今回参考にしているAWSブログの記事（*）でも記載されている通り、AWS CodePipeline/AWS CodeBuildやその他AWS CodeDeployといったサービスを活用することでコンテナに対してCICD機能を素早く実装することが可能です。
*. https://aws.amazon.com/jp/blogs/news/developing-twelve-factor-apps-using-amazon-ecs-and-aws-fargate/
CICD機能はコンテナを実行させるうえで必須の機能というわけではありませんが、12 factor appで述べられているようにビルド・リリース・実行の3ステージを分離させて品質の高いシステム運用を可能にするためには欠かせない仕組みです。
オンプレミスでシステム運用を行っていた時点で既にCICDを活用できている、というケースはそれほど多くないように見受けられており、またCICDを実装するためには準備が必要ということもあって利用を敬遠されることもありますが、AWSのサービスを活用することでCICDの導入ハードルを低くすることが可能です。特にシステム構築の初期段階でCICDを実装して手順を整備しておけば運用を定着させることも難しくありません。逆に案件の途中やシステムリリース後にCICDを組み込むと作業負荷が高くなり断念してしまう恐れもありますので、初期構築時に仕組みを入れることを推奨します。
2点目について、12 factor appでオブザーバビリティについて明確に述べられているわけではありませんがコンテナの特徴である並行性や廃棄容易性といった観点からこのオブザーバビリティは非常に重要になってきます。
コンテナは必要に応じてスケールアウト・スケールインを繰り返します。更に1点目の特徴で述べたCICDを用いて業務処理時間中に無停止でコンテナを作り替えてアプリケーションのアップデートを行うことも可能です。
このようにシステムがどんどんと変化していくことが当たり前の状況の中ではシステム全体が今現在どういう状況なのか全体像をとらえることが難しくなってきます。そういった課題に対してAWS X-Rayを用いることで解決が可能です。AWS X-RayはAPM(Application Performance Monitoring)の一種でECSタスクに対してはサイドカーコンテナを実装することによりコンテナ内部のパフォーマンスに関する情報を抽出し、マネジメントコンソール上でグラフィカルに確認することができます。また、Amazon API GatewayやAWS Lambda等ではより簡単にAWS X-Rayと統合することが可能ですのでシステムの中の業務通信が通る複数のコンポーネントでAWS X-Rayを有効にすることによりシステム全体の状況を詳しく把握することが可能になります。
なお、サイドカーコンテナを使うことですぐにECSタスクでAWS X-Rayを利用することは可能ですが、システム毎に最適な情報を出力するにあたって、一部アプリケーション側に手を加えるケースがありますので、こちらも1点目のCICDと同様に案件の初期段階で実装しておくことでその後のテストや保守運用を楽に高品質にすることが可能です。
これらAWSサービスを活用することは12 factor appというプラクティスをAWS上で少ない労力で形にすることに寄与すると考えています。
まとめ
この記事では12 factor appを意識してAmazon ECS/AWS Fargateを用いた構成を使ってオンプレミスからの移行を実現する際にポイントとなる点を解説しました。
更改前のオンプレミスのシステムの時点ですでに12 factor appに沿って作っている、ということはあまり無いのではないかと私の経験上感じています。
AWSの利用とそれに合わせて12 factor appを意識してクラウドネイティブな構成を実現することまで行うのは非常にハードルが高いことのように感じられることもありますが、AWSの関連サービスは12 factor appに記載されている方法論を形にすることを想定しているためこれを活用することでスムーズに実現することが可能です。
また、各ステークホルダーが現行システムで行っている処理・運用の内容やアプリケーション担当・インフラ担当といった役割面に固執することなく、クラウドネイティブを志向したときに何が最適なのかということを考えて移行プロジェクトを進めていくなど考え方をクラウドネイティブに寄せていくことが成功のための重要なポイントだと考えます。
参考URL