ビジネス+IT

ビジネス課題別で探す

ITジャンル別で探す

関連ジャンル

Web開発 クラウド 開発総論

会員限定

2018年01月11日

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

サーバレスコンピューティングは新しいシステム開発手法である。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氏(右)。

photo


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

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

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

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

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

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

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

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

Compute as backend

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

photo


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

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

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

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

photo


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

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

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

GraphQL

 GraphQLはFacebookが2012年に開発したクエリ言語です。

 このパターンでは単一のエンドポイントがLambda Functionとして存在し、ここでGraphQLが実行され、そこに接続された複数のデータソースで処理されます。

photo


 クライアントがデータをリクエストすると、GraphQLエンドポイントのLambda FunctionがGraphQLを実行、DynamoDBのデータ結合などの処理を行ったうえで答えをクライアントに返します。

 これは非常に強力で効果的なパターンです。

Legacy API Wrapper

 これはAPIファーストなアプローチを実現する場合のパターン。とりわけシステム内部ではSOAPやXMなどを使ったアプリケーションを、API Gatewayを使ってREST API対応のモバイルアプリケーションやWebアプリケーションとする場合に使われます。

photo


Compute as glue

 これは私がいちばん好きなパターンです。

Web開発 ジャンルのトピックス

一覧へ

PR

注目のIT導入支援情報

一覧へ

注目のイベント・セミナー情報

一覧へ

イベント・セミナー情報の登録(無料)

記事アクセスランキング

イベント・セミナー情報アクセスランキング