AWSへ移行したレガシーシステムに、新機能はどうやって追加すべきか？　既存の仕組みとサーバーレスな開発を共存させるアーキテクチャ

既存システムをAWS移行後に、新機能を追加するには？

福井厚氏（以下、福井）：みなさん、こんにちは。AWSの福井です。私はサーバーレススペシャリストとして、ふだんはサーバーレステクノロジーを使ったモダンアプリケーションの開発を支援している、ソリューションアーキテクトです。よろしくお願いいたします。

今村優太氏(以下、今村）：みなさん、こんにちは。AWSの今村と申します。私はふだん、お客様のプロトタイプ開発支援をメインとしているソリューションアーキテクトです。本日はよろしくお願いいたします。

木村友則氏（以下、木村）：みなさん、こんにちは。AWSの木村と申します。私は業種業態を問わず、さまざまなお客様の構成検討の支援をさせていただいている、ソリューションアーキテクトです。

福井：では本セッションについてご紹介したいと思います。本セッションは「既存システムをAWSに移行したあとに新機能を追加する」ということをテーマに、実際にロールプレイでその状況をお見せして、そのあと後半でプロタイプ開発をお見せし、動くものをご覧にいれたいと思います。それではよろしくお願いいたします。

今村：ここからは福井と木村の2名にて、ロールプレイでお送りしていきます。場面としては、書籍販売を行っているECサイトです。こちらを運営しているお客様から新規プロジェクトの相談を受け、ミーティングをしているという場面をご想像いただければと思います。それでは始めていきたいと思います。

木村：最近やっと、弊社のECサイトのAWS移行を終わらせることができました。福井さんにいろいろと相談に乗っていただいて非常に助かりました。さっそくなんですけれども、その後、社内から新機能の追加要望が出ておりまして、また相談に乗っていただきたいなと思っています。

福井：移行が無事に終わってよかったですね。

AWS移行時のシステム構成はシンプルな3層構造

福井：今回はどういった開発をされるのでしょうか？

木村：資料を用意しておりますのでご案内したいと思います。まず最初に、移行したもともとのシステムの構成のおさらいからご説明しておきます。こちらが弊社の書籍販売のECサイトの構成図になっているんですけれども、シンプルな3層構造ですね。

フロントにElastic Load Balancingを置いて、その下にAuto Scaling groupでAmazon EC2を並べています。データベースとしてはAmazon AuroraのMySQLエンジンを使ったものを並べております。Auroraなのは可用性と将来的な拡張性を重視して選択しています。あとはセキュリティの対策としてAWS WAFも使用しております。

木村：こちらが今回のプロジェクトの内容です。お客様から非常に多く要望をいただいていたもので「新刊が出たらすぐに購入したい」というお声が非常に多かったです。なので今回は、そのようなお客様の声に応えたいなと考えて機能開発を行おうと思っております。

具体的な実現したいこととして、こちらのスライドに書かせていただきました。販売予定の書籍を一覧で表示できることであるとか、販売開始を知りたい書籍を登録できること、そしてその登録した書籍の販売開始のタイミングでメールを通知できるということを考えております。

現在のシステムのマスターデータには販売中の書籍情報のみしか入っていないので、新刊情報のデータベースへの取り込みですとか一覧表示、登録のためのページですとかメール通知なんかも必要かなと考えております。

福井：なるほど。プロジェクトの内容はだいたいわかりました。

サーバーレスな開発への期待と不安

福井：今のECサイトはアーキテクチャを変えずに、AWSにそのまま移行されたと記憶しているんですけれども、今後の開発方針についてはどうお考えでしょうか？

木村：そちらも今、非常に悩んでいるところがあります。

今現在のECサイトのコードに機能を追加して拡張を継続していくのか、もしくは新しく別のコードを用意するのかについて考えております。従来のやり方でやったほうがノウハウもありますし、期間も短くなるはずだと考えております。

ただ、従来のやり方どおりにやってもよいかなとも思っているんですけれども、せっかくAWSに移行したので、やはりAWSに適したやり方に変えていきたいなと考えております。その方法としてサーバーレスという言葉を最近よく聞くので、非常に興味を持っているところなんです。

でも我々自身、まだサーバーレスのノウハウもございませんし、我々の現在のスキルセットで開発できるかどうかというところも不安を感じております。

福井：なるほど。お悩みはよくわかります。無理してすぐにサーバーレスに変える必要はないかと思うんですが、今後徐々に段階的にサーバーレスの機能、便利さを取り入れていくのもありかなと思います。

追加機能だけをサーバーレスで開発するという提案

福井：今までまったくご経験がないので不安があるのは当然のことだと思いますが、特にサーバーレスな開発にご期待されていることって何かありますか？

木村：はい。いくつかあります。

我々は今後もビジネスを拡大していきたいなと思っています。書籍の取り扱いもどんどん増えておりますし、お客様もどんどん増えております。こういったかたちでビジネスがどんどん拡大しても、やはりこれ以上運用負担は増やしたくないなということを一番感じております。

現在のシステムは、先ほども申し上げたとおりEC2、仮想サーバーを使って構築しております。これ以上増やしたくないなと思ってます。どうしても仮想サーバーを使うと、ふだんのセキュリティの対策であるとかメンテナンス工数がかかっておりますので、ここはあまり増やしたくないなというところです。

あとは今後いろいろな商品が増えるにあたってスケーラビリティを高めたいであるとか、新しい商材を扱うにあたっても変化に強いシステムにしていきたいなと思っています。

福井：なるほど。期待されているポイントがよくわかりました。それでは、現在のAWSに移行されたECサイトは現状のままご利用いただいて、今回新しく追加される機能だけサーバーレスな開発を進めてみてはいかがでしょうか？

木村：なるほどですね。そういった方法もできるのですね。今のお話ですと、ECサイトは現在のまま、新刊情報のサービスだけをサーバーレスで作って連携させるということだと理解いたしました。ですが、そういった場合にどうやって連携するのかが、少し気になっております。ぜひその方向でお話を伺ってみたいと思います。

新刊情報取得と認証の現状ヒアリング

福井：ご期待はわかりましたので、じゃあ実際に具体的な要件についてお伺いしていきたいと思います。

まずは新刊情報というのはどこから、どういったかたちで取り込むのでしょうか？

木村：それは外部の契約先がございまして、そこからCSVの形式でデータを取得できるようになっております。こちらはもともとシステム連携を前提においた仕組みなので、開発ガイドのようなかたちで、取り込みの仕方も情報もすでに入手しております。

福井：なるほど。取り込んだデータをどこに保存するかは後で検討するとして、取り込み自体には特に問題なさそうですね。

現状のECサイトについてなんですが、認証はどうされていますか？　新刊情報の認証も併せてどうやろうと思われているかお考えをお聞かせいただけますか。

木村：現在のECサイトでは、書籍のマスターデータと同じデータベースの中に認証情報のテーブルを持っています。ユーザー名とパスワードで認証させている感じですね。新刊情報サービスにおいても、ECサイトと同じ認証情報を使いたいなと思っています。

今お話を伺いながらちょっと考えていたんですけれども、こういった時はなにか共通で使える認証APIのようなものを作ったほうがよいのでしょうか？

福井：そうですね。認証APIを作る方法も確かにあるんですけれども、今回は今あるデータベースの認証情報だけを使って、新機能開発の新サービスに認証する機能を追加してはいかがでしょうか？

木村：なるほど。そういったやり方もあるのですね。それであればよくわかりました。

ワークロードと開発言語

福井：それでは次に現在のワークロードについてお尋ねしたいのですが、ページビューとかスパイクとかの状況はいかがでしょうか？

木村：現在我々のサイトには登録会員が10万名程度いらっしゃいまして、だいたい月に1回程度購入してくださるようなアクティブユーザーの方が10パーセント、だいたい1万名くらいおります。

スパイクというのはめったにないんですけれども、全体のアクセスとしては通勤時間帯とかお昼休み、あと夜間が比較的多いかなというところです。ただ人気の作家さんの新刊が出る時、例えばメディアに紹介されたような時っていうのは、一時的にスパイクのようなことが発生することもございます。

月刊のページビューとしては、今だいたい100万くらいですかね。秒間は多くても数十くらいです。スパイクが発生している時に限り、瞬間的に数百くらいを記録するようなことがあるといったレベルだとお考えていただければと思います。

福井：なるほど。よくわかりました。そのワークロードを聞いた限りは、今回の新刊情報サービスが増えても特に問題はなさそうかなと思います。ただ、おっしゃったとおり人気の作家さんが新刊を出すという時には一時的にリクエストが増えると思うんですけど、今回利用するサーバーレスのテクノロジーを使っていただければ、そのあたりを自動的にスケールするような機能もございますので、安心していただければと思います。

もう1つお尋ねしたいんですが、ふだんお使いの開発言語とかデータベースというのはどのようなものでしょうか？　

木村：現在のECサイトはJavaで開発をしておりました。最近は一部の機能の追加にReactを使ったりですとか、機械学習の調査のためにPythonなんかも使っております。データベースはいろいろあるんですけれども、MySQLが一番多いかなと思います。

福井：なるほど。けっこう新機能を取り入れられているんですね。JavaやReact、Pythonをお使いということであれば、サーバーレスな開発でも問題なく進めていただけると思います。最後にこのシステムの、新刊サービスのリリース時期を教えていただけますか？

木村：だいたい遅くとも、半年後くらいまでにはリリースしたいなと思っています。今いろいろとお話を伺ったところ、我々の現在のスキルセットも活かせそうなので、すごく安心いたしました。ただ、やはりサーバーレスは初めてなので少し不安も感じているので、ぜひそのあたりを詳しく教えていただきたいと思っています。

福井：承知しました。これまでの内容をもとに、実際にアーキテクチャをディスカッションしていきましょう。

木村：はい、よろしくお願いします。

フロントエンドにシングルページアプリケーションを勧める理由

福井：大方針としては、先ほどReactもお使いになっているということなので、Webのフロントエンドはシングルページアプリケーションというアーキテクチャをおすすめしたいと思います。

このシングルページアプリケーションのアーキテクチャで、Reactを含むJavaScriptとかHTMLの静的ページなどはAmazon Simple Storage Service、S3ですね。こちらのWeb公開の仕組みを使いまして、クラウドフロントでキャッシュ、CDNでキャッシュされた情報をダウンロードしてWebブラウザのほうに表示していただくということです。

実際の登録処理についてはAPIをコールし、React側からAPIを呼び出して操作を行うというかたちを取りたいと思います。その際に利用できるAWSのサービスがAmazon API Gatewayというサービスです。また、その後ろで処理を行う、コードを実行する仕組みとしてAWS Lambdaというのをご利用いただけるかと思います。

Lambdaからデータをアクセスしたり、あるいはデータを登録したりするデータベースとしては、今回はスモールスタートということでAmazon RDSのシングルインスタンスから始めてはいかがでしょうか？

木村：なるほどですね。

福井：今ご紹介したサービスを、もう少し詳しくご紹介していきたいと思います。まずAmazon API Gatewayですね。

こちらはサーバーレスなサービスとして、スケーラビリティとか可用性をAWSが担保しておりますので安心してお使いいただけますし、APIの公開に対してコーディングなどは一切不要です。

またRSET APIやWebSocketのAPIをバックエンドに、LamdaやWebサービスやその他のAWSサービスを使って公開することが可能です。さらに認証認可の機能ですとか、キャッシングの機能も提供しております。さらに、実装が難しいと言われるスロットリングの機能もあらかじめ提供しております。

こういった重労働なんですが、直接ビジネスの付加価値を生まないようなものはサーバーレスなAWSのサービスにオフロードしていただくことで、すばやく開発を実現することが可能になります。

APIを中心とした開発にシフトするメリット

福井：次のサービスはAWS Lambdaです。Lambdaは先ほど少しご紹介いたしましたが、アプリケーションコードを実行する環境を提供してくれるサービスです。

お客様には実際にビジネスに有効なアプリケーションのコードだけを開発していただいて、それ以外のランタイムやOSのパッチ適用といったものは一切考える必要はありません。また自動的にスケールもしますので、急なワークロードが発生したとしてもそれに自動的に対応することができるサービスです。

ここの例ですね。デザインパターンとして挙げたように、例えばなにかのイベントに応じてLambdaを実行したりとか、ワークフローの中でLambdaを実行したりするようなこともできるようになってますが、今回はAPI Gatewayのイベントですね。リクエストに応じてLambdaを実行することができます。

木村：ご説明ありがとうございました。API GatewayとLambdaはすごく便利そうでいろいろと活用の幅がありそうだなということがよくわかりました。お話を聞いていると、今後も我々の開発の中ではこういったAPIを前提に開発をしたほうがよいのかな、という気がしてまいりました。

福井：今回の開発をきっかけに、APIを中心とした方向に開発をシフトしていただくといろんなメリットがございます。

1つは、一つひとつの機能の変更の影響を小さくできるので修正や改修がすばやく行えるということと、新機能のデプロイ、リリースが、これもすばやくできるようになるということです。

エンドユーザー様の声を聞いて新しい機能を追加したいという時に、すばやくそれをリリースできるようになるということで、結果として御社のビジネスも迅速に改善でき、サービス提供ができるようになるというメリットがあります

木村：なるほどですね。改めてご説明いただいてAPIを中心として開発のメリットというのがすごくよくわかりました。

LambdaのバックエンドにRDBMS？

木村：ところで少しお聞きしておきたいんですけれども、Lambdaで使うデータベースの選定に注意するところはないのでしょうか？　今までいろいろと見てきた中で、LambdaとRDBMSの組み合わせはあまりよくないというようなことを聞いたことがあります。一般的には、DynamoDBのほうがよいというのを見たことがあるんですけれども。

福井：おっしゃるとおりで、こちらですね。

今回はRDSのMySQLデータベースをおすすめしているんですけれども、以前はLambdaのバックエンドにRDBMSを使うのはアンチパターンと呼ばれていました。

それが2020年7月にRDS Proxyというサービスが出まして、これにはプーリングしてくれる機能があります。

コネクションプーリングすることによって結果的に、LambdaがスケールしたとしてもRDS Proxyがそのコネクションのリクエストをプーリングをさばいてくれることにより、バックエンドのRDBMSに負荷をかけることがなくなりました。今後はLambdaのバックエンドにRDBMSを使うのも、有効な手段となります。

木村：なるほどですね。そういうお話ですと、我々みたいにリレーショナルなデータベースを使うようなユーザーにとっても非常にうれしい機能ですね。かつ、サーバーレスな開発にとってもメリットが大きそうだなと感じております。

Amazon RDS Proxy、4つの特徴

福井：今ご紹介したAmazon RDS Proxyですけれども、Amazon RDS向けの高可用なフルマネージド型のデータベースプロキシというところが特徴になります。

大きく4点特徴がございまして、1つは先ほど申し上げましたプールの機能ですね。データベース接続をプールおよび共有することで、アプリケーションやフロントのスケーリングを改善します。

それからアプリケーションの可用性を高めて、データベースのフェイルオーバー時間を短縮します。これはなにを言っているかというと、もしバックエンドでなにか障害が起こってフェイルオーバーしたという時にも、このRDS Proxyに接続しているアプリケーションは影響を受けることなく、自動的にフェイルオーバーした先に切り替えてくれる機能を提供しております。

またセキュリティの強化という面もございまして、RDS Proxyを使うことによって、1つにはまず、これまでのユーザー名パスワード認証に代わってIAM認証を使うことができるようになったり、あとはTLSの1.2をサポートしておりますのでよりセキュアな接続ができるようになったりします。

さらにAWSのAmazonのSecretsサービスというものがございますが、こちらと連携することによってデータベースのユーザー名パスワードをセキュアに管理するという機能も提供しておりますので、これらを利用することによってよりセキュアなシステムを構築することが可能になっております。

最後は、フルマネージドなデータベースプロキシということで、RDSと完全な互換性を持っております。コードを変更することなく、そのままお使いいただけるというメリットがございます。

Lambdaに設けられた15分という時間制限

福井：もう1つの機能としては、CSVの新刊取り込みですね。それと予約された人たちが新刊が出た時にその人たちにメールを送信するという機能があるかと思うんですけども、この2つはバッチ的な処理です。例えば定期的な時間実行でその処理を実行してはどうかと思います。

その時に、この2つの処理を連携して実行する、またエラーのリトライや、なにかエラーが起こった時の条件分岐といった処理を管理してくれるStep Functionsというサービスがございますので。今回はStep Functionsを使ったバッチ処理をしてはいかがでしょうか。

まず最初に、新刊処理のCSVの情報取り込みについてご紹介したいと思います。こちらは図にありますように、AWSのAmazon Elastic Container ServiceとAWS Fargateというコンテナのサービスを使って、実装してはいかがかなと思っております。

具体的にはStep FunctionsからAmazon EventBridgeというスケジューラーを使って、Step Functionsを定期的に実行するんですけれども。その中でECSとFargateに対してリクエストを投げて、ECSとFargateの中でCSVの読み込みとデータベースの更新を行いたいと思います。

なぜコンテナを使うのかなんですが、もしCSVが大量にあった場合に読み込み処理の実行時間が長くなってしまう可能性があるからです。Lambdaには15分という時間制限がございますので、それを考慮して今回はコンテナでこの処理を実行してはどうかなと思っております。

木村：なるほどですね。確かにお話を聞いていると、Lambdaの時間の制限というのは注意が必要だということはよくわかりました。実際新刊情報を含むCSVも毎日データのサイズが違うので、おっしゃるとおりコンテナを使ったほうがよさそうだなということも、今よくわかりました。この実行時間などの制限にかかるかどうかというのが、コンテナとLambdaの使い分けの指針にもなりそうだなと思っております。

マイクロサービス全体を管理するStep Function

福井：そうですね。次は2つ目の処理、対象ユーザーに対してメールを送信する処理です。

こちらは1件1件の処理時間は非常に短いので、これはLambdaでまかなえるのではないかと思っております。AWS Lambdaを実行して、今回はAmazon Simple Email Service、これはSESと呼ばれるSMTPのサービスで、これを使ってメールを高速に送信したいと考えております。

今ご紹介した2つのバッチ処理を連携させるためのサービスとして、Step Functionsというのを少しご紹介したいと思います。

このStep Functionsはマイクロサービス全体を管理して、ワークフローの処理を宣言的に定義します。Amazon States Language、ASLという言語を使ってStep Functionsの実行フローを宣言的に定義しておくと、そのとおりに実行してくれます。

サーバーレスのスケーラビリティや可用性については、これをAWSが担保しているサービスということになりますが、LambdaをはじめとしてさまざまなAWSのサービスをこのワークフローの中から実行することができます。

先ほど申し上げました条件分岐であるとか、エラーのリトライ処理であるとか、例外が発生した時の処理の分岐ですとか、こういったものを事前に定義しておくことができます。場合によっては、なにか人が承認するようなものが必要なワークフローも定義することができるようになっています。

既存システム＋追加機能の全体アーキテクチャ

福井：既存システムを含めての全体アーキテクチャをまとめますと、この図のようになります。

今回のECサイトのシステムの横に、サーバーレスのテクノロジーを使った新刊情報サービスを構築していくと、こういったアーキテクチャになるかと思います。

木村：ありがとうございます。ご提案、非常にありがたいと思っています。今お話いただいたとおり、このアーキテクチャであればECサイトと新刊情報サービスの連携も問題なくできそうだなということが、よくわかりました。我々もサーバーレスな開発に挑戦できそうだなと思っています。

福井：そうですね。このECサイトでは、以前のシステムを移行するにあたってPoCを実行していただいたと思うんですけれども、今回新刊情報サービスのアプリケーションを開発するにあたっては、ぜひプロトタイプを開発することをおすすめいたします。

プロトタイプを開発することによって、技術的なブロッカーを事前に潰したり、あるいはAWSのサービスの使い方のノウハウを身につけたりすることができます。そのノウハウをもって本番の開発に活かしていただくことができますので、ぜひプロトタイプ開発をおすすめしたいと思います。

木村：なるほどですね。たしかに、プロトタイプ開発のようなステップを踏むのはよさそうです。ぜひ引き続き、相談させていただければと思います。

福井：もちろんです。よろしくお願いいたします。

今村：以上でロールプレイングを終了します。実際のお客様との打ち合わせでも、このように既存システムとサーバーレス開発との連携でご相談を受けるというケースがよくあります。本セッションを、みなさまの解決策の一例として参考にしていただければ幸いです。

福井：それではこれで前半のセッションは終わりたいと思います。

今村：後半のセッションでは、今回提案したアーキテクチャの一部をプロトタイプとして実際に開発していきます。今回、福井が提案したサーバーレスを中心としたアーキテクチャですけれども、開発をどうやって行なっていけばよいのかという点について、実際にプログラムを書く様子をご覧いただきながら解説していきたいと思います。こちらは私、今村が担当させていただきますので、ぜひ続けてご視聴いただければと思います。

福井：それでは前半のセッションを終わりたいと思います。みなさん、ありがとうございました。