「サーバレス」でスケーラブルかつ堅牢なシステムを構築するための方法

ありがとうございます！
いいね！した記事一覧をみる

会員になると、いいね！でマイページに保存できます。

Web開発・アプリ開発

|

タグをもっとみる

サーバレスコンピューティングは新しいシステム開発手法である。Serverlessconf Tokyo 2017で紹介された、スケーラブルで堅牢かつ高性能なアプリケーションの構築に役立つ6種類のデザインパターンを紹介する。

執筆：Publickey 新野淳一

　2017年11月2日、3日の2日間、東京都内でサーバレスコンピューティングのイベント「Serverlessconf Tokyo 2017」が開催されました。

　サーバレスコンピューティングもしくはサーバレスアーキテクチャと呼ばれるアプリケーション実行環境は、一般にサーバのことを意識せずにアプリケーションを実行できる環境のことを指します。

　そのサーバレスコンピューティング環境の実装として一般的なのが、あらかじめアプリケーションとして実行したいコードを関数として登録しておくと、指定されたイベントによって自動的に関数が呼び出されて実行されるという、いわゆるFunction-as-a-Service（FaaS）です。

　しかし、このイベントドリブンな関数をどのように組み合わせて適切なシステムを構築するべきなのか、多くのプログラマにとって新しい課題です。

　そこで重要な指針になるのが、適切なアーキテクチャやデザインパターンでしょう。本記事で紹介するServerless Conf Tokyo 2017のセッション「Serverless Patterns and Architectures」は、まさにそうした内容をカバーしたものでした。

Serverless Patterns and Architectures

　AWSでAPI GatewayとServerlessのPrincipal Product Manager、Dougal Balantyne氏（左）、A Cloud GuruのPeter Sbarski氏（右）。

　以下はBalantyne氏とSbarski氏の発言をダイジェストでまとめたものです。

　サーバレスアーキテクチャを知ることは、スケーラブルで堅牢かつ高性能なアプリケーションの構築に非常に重要です。

　私たちは、強力なデザインパターンの理解こそが、本当にスケーラブルで堅牢なアプリケーションの構築につながると信じています。

　そして再利用可能なパターンを用いることで、そうしたアプリケーションの開発はさらに容易になると考えています。

関連記事

　まず、サーバレスの事例を3つ紹介しましょう。米国のオンライントラベルサイトExpediaは、1カ月で12億ものリクエストをサーバレスで処理しています。まさに驚異的です。

　米国の金融規制当局FINRAは、毎日5000億件もの米国の株式市場の取引をすべて追跡し、検証しています。これまで大規模なHadoopをベースに展開していましたが、サーバレスを取り入れたことで、よりスケーラブルで高速な処理を実現しました。

　金融関係の情報提供機関であるトムソンロイターは、1秒あたり4000件のリクエストをサーバレスで処理することで、スケールアップ、スケールダウンをオンデマンドで実現しています。

　こうしたサーバレスアーキテクチャでのソリューション構築における、基本的なパターンを紹介しましょう。

Compute as backend

　Restful APIがAWS API Gateway経由でAWS Lambda Functionにつながっています。

　クライアントがリクエストをAPIに送るとこれがLambda Functionを呼び出し、そこからさまざまな処理が行わえて、結果がAPI Gateway経由でクライアントに戻されます。

　クライアントからはサーバレスがバックエンドにあることはわからず、API GatewayがAWSのサービスを統合する役割を果たしています。

　このパターンでは、API Gatewayが必ずLambda Functionを呼び出さずともよく、DynamoDBを呼び出すこともあります。

　われわれはこれをハイブリッドアーキテクチャと呼んでいます。このアーキテクチャはAPI Gatewayを活用することで、Lambda Functionを呼び出すだけでなく、通常のアーキテクチャのアプリケーションを呼び出すこともできます。

　すべての機能がAPI Gatewayにつながっており、ここで統合されます。

　ですので、サーバレスアーキテクチャへの移行はまずこのパターンからはじめて、時間をかけて通常のアーキテクチャから移行していけばいいのではないか。おそらく移行にもっとも手間取るのはデータの永続性に関する部分だと考えられる。

　例えば、予約サイトであれば予約の処理部分はトラフィックが増えても対応できるようにサーバレスにして、それ以外のレガシーな部分は残しておいて、徐々に移行すればよい。