本記事で取り扱うモダナイゼーション
モダナイゼーションの定義やその説明については、AWSにおいてサーバレスを活用したモダナイゼーションが企業にもたらす価値とはの記事に詳しくまとめていますが、今回はクラウド開発におけるアジリティやコストの側面でモダナイゼーションを行なうメリットに注目していきたいと思います。つまり、オンプレミスからサーバレス、コンテナやマネージドなデータベースサービスに移行するケースを想定してもらえればと思います。
オンプレからモダナイゼーションを行なうメリット
スキルの向上とクラウドコストの最適化
オンプレミスからAWSに移行する際、仮想マシンへのリフトアンドシフトを行なうことが最も学習コストも低く安全なやり方ではあります。しかし、その場合に重要な学習の機会を逃してしまっているかもしれません。もし、内製のチームが弊社のようなAWSパートナーの支援を受けながら、リフトアンドシフトでの移行プロジェクトを成功させたとしましょう。しかし、その場合には仮想マシンとその周辺サービスの使い方のみの知識しか得ることが出来ません。これは現在のAWSが提供するサービスの豊富さからすると部分的なノウハウしか得ることで出来ないので、やはりもったいないのではないかなと筆者は感じします。
仮想マシンの使い方のみに慣れてしまった組織では、AWSへの移行終了後もAmazon EC2 + Auroraの構成のアプリがサイジング等も正確にされることなく乱立していくパターンも多いのではないでしょうか。
当然ながらこれらは固定費がかかるサービスではあるので、アプリケーションが追加されるたびにそれに応じてコストは増加していきます。もし、外注業者に開発を委託している場合などはその保守費用などもかさんでくるでしょう。
このような状況の中で、クラウドコストの最適化や内製化を行なうことで、膨れ上がるシステムへのコストを最適化したいという相談も増えてきているように感じます。筆者としてはオンプレミスからAWSへ移行する際に、クラウドネイティブな構成に移行することでAWSの包括的な知識やノウハウを手に入れて、その後の開発も素早くコスト最適な状況を作りながら世の中に価値を提供していける体制を作っていくのが一つの良いオプションではないかと考えています。
システムの安定性
筆者の経験則でいうと仮想マシンで構築されたシステムよりも、クラウドネイティブな仕組みを上手く使って構築されたシステムのほうが安定性が高く、トラブルやエラーの少ないシステムになるケースが多いでしょう。クラウドネイティブなサービスのほうがエラーハンドリングの仕組みも充実していますし、トラフィックが増えたときのスケーリングなども自動でやってくれます。やはり、AWSさんのような超絶優秀なエンジニアの方たちが作った仕組みにどっぷりと浸かるほうが結果としてトラブルやエラーも少なくて済むでしょう。
オンプレからモダナイゼーションを行なうデメリット
一番のデメリットはその学習コストでしょう。初学者からするとたくさんのAWSサービスの特徴や仕様を体で理解して、最終的にはユースケースに合わせて最適なAWSサービスが選定できるだけのスキルをつけることが求められます。ざっと以下のようなことを覚える必要は出てきそうです。
- Aサーバレス・コンテナに属するサービスの特性や使い方。AWS Fargate, Lambda, S3, Step Functions, DynamoDBなど
- 各AWSサービスの制約条件への理解。
- Lambdaは15分しか動かない
- 同時実行数は1,000だが、上限緩和申請が可能
- サーバレス・コンテナを前提とした開発フロー
- AWS上でのアーキテクチャ設計。場合によってはPoCの実施
- Infrastructure As Codeの設計・実装
- AWS Lambda及びAWS Fargate上でのアプリケーション実装
- CloudWatch等を使用した監視及びエラー通知
- バックアップとリストアの実装及び設計
- DynamoDBの使用を考える場合はNoSQLへの理解
- 負荷試験
- 各種制約に引っかからないか。想定トラフィックを捌くに当たってボトルネックは発生しないかなどチェック
また、オンプレからのモダナイゼーションは初期の導入コストが大幅に増えることに成るでしょう。AWSの仕組みに合わせて大幅にアーキテクチャ全体を作り直す必要が出てきます。今のソースコードを流用することも不可能ではないですが、ソフトウェアの環境やバージョンに依存するので、あまり期待することが出来ないでしょう。基本的には作り直しを前提で考える必要があります。
オンプレからのモダナイゼーション事例
株式会社LIXIL様の会計システムのモダナイゼーション事例
SAP + ERPパッケージでオンプレで動いていた会計仕分けシステムをAWS上に移行してモダナイゼーションを実施しました。AWS上でサーバレスをベースにシステム自体を作り直し、データ移行を行なうことでマイグレーションを実施。成果として、サーバにかかる固定費がなくなりました。バッチ処理が実施される深夜の数時間のみのコストでシステムが稼働できるようになり、大幅なコスト削減に成功した事例になります。
アーキテクチャとその仕組み
- 売上収集システムに上がってくる請求情報を日時でS3に取り込む
- 会計処理のワークフローを実装したStepFunctionsで仕訳処理を実施。実施後のデータはDynamoDBへ保存
- 月の締め日になれば、月次売上仕分けサービスが起動。同じく締め処理のワークフローを定義したStepFunctionsで処理を実行
- 最終CSVにデータを出力して仕分け収集システムへ転送
本移行プロジェクトの進め方
- 移行前のオンプレミスで動いているシステムの仕様書を元に要件を整理してAWSアーキテクチャの設計の実施
- 使用するDBは今回のデータの特性からDynamoDBを選定。AWSアーキテクチャを決めていくことと同時にデータモデリングも実施
- 開発を実施。既存ソースコードは流用しない判断を行い新たにPythonで実装していくことに決定。Serverless Frameworkでインフラのコード化も実施
- データ移行スクリプトの開発。オンプレミスDBのダンプデータを移行スクリプトを使ってDynamoDBに投入
- 負荷試験にて一日でバッチ処理が終わるかどうか、その他のボトルネックが発生しないかをチェック
- 監視構成の実装
- 本番リリース
CRMシステムのオンプレからのモダナイゼーション事例(顧客名非公開)
オンプレミス上で動いていたCRMからのお問い合わせデータをAIを使って担当部署に振り分けるアプリケーションをAWSに移行して同時にモダナイゼーションを実施した。モダナイゼーションの結果としては大幅なTCOコストの削減やメンテナンス負荷の削減に成功した
- Saleforceに上がってくる問い合わせデータを、AppFlow + Lambdaで取り込んで、SageMaker上にホストされたデータ抽出AIに送る
- ワークフロー処理ができるStepFunctionsで抽出された問い合わせデータの整形処理
- 担当部署振り分けAIにより各部署へ振り分け
移行プロジェクトの進め方
- AWS上でアーキテクチャを設計、実際に動くものをPoCとして開発。まずはオンプレミスで動いているものと同じ要件がAWS上で満たせるかをチェック
- 既存のソースコードをAWS Lambda上に移行するための計画と検証の実施。最終的には部分的に作り直したC#のコンテナをLambdaにデプロイ
- 開発の実施。アプリ本体はC#でLambda実装。CDKを使ってインフラのコード化も実施
- データ移行の実施。オンプレのデータベースのダンプデータを新しいDBのスキーマ構成に変更するためのスクリプトを開発して移行
- 負荷試験の実施。1時間に100件程度の問い合わせが発生するので、それらが問題なく捌けるかボトルネックは発生しないかなどをテスト。合わせてCloudWatchによる監視の構成も実装
- 本番リリース
まとめ
オンプレからAWSに移行する際にはリフトアンドシフトが一番ベターな選択肢かもしれませんが、せっかくAWSに移行するのであれば、クラウドのメリットを最大限生かせるようにモダナイゼーションを行ってみるのは如何でしょうか。
一度、リフトアンドシフトを行ってからモダナイゼーションを行なう2ステップのパターンが議論されるケースもありますが、筆者はそれにはあまり賛成の意見は持っていません。おそらくリストアンドシフトが完了した時点で満足してしまいその先のモダナイゼーションのステップに行くのはモチベーションとして困難になるのではないでしょうか。
もちろん、モダナイゼーションを行なうこと自体が目的ではありません。モダナイゼーションを行なうことで組織構造を変革し、素早い価値提供を顧客に提供できるようにシステムは組織を改革していくことが目的です。そのための一歩として、クラウド移行のタイミングでモダナイゼーションを実施してみるのも一つの良い方法でしょう。