読者です 読者をやめる 読者になる 読者になる

ボクココ

サービス開発を成功させるまでの歩み

AWS Summit に参加して感じた新しいWEBシステムのかたち

AWS

http://www.awssummit.tokyo/images/header_logo.png

6月3日の AWS Summit Day2 に参加した。

AWS Summit Tokyo 2015 - クラウドで、未来を「今」に。- 2015年6月2~3日 グランドプリンスホテル新高輪にて開催

今までのAWS Summit といえば、どちらかというと大企業が AWS を導入を検討する、事例を知るのに集まる場としてスーツ姿な方々が集まるようなカンファレンスなイメージだったが、今回から デベロッパーカンファレンス という開発者向けのイベントも同時開催だったため、こちらに参加した。まぁとはいえそこでも割と大きめな企業が事例の紹介とかが多かった。ぶっちゃけ事例話は自分的には興味がない。そういう企業のスタイルを真似る必要はないと思っている。起きた目の前の問題に対して自分で調べて解決すればいいだけの話なのだから。事例の発表はたいてい自社のサービスのプロモーションのことと、起きた問題、経緯の話くらいがほとんどで、最終的に We're Hiring で終わるのよね。

その話はさておき、発表の中でAWSの中の方々による発表で2つの新しいシステムのかたちを感じることができた。今回はそのレポートをする。

2 Tier Architecture

AWSAPIサーバーレスなサービスを実現することができる。従来のAPIサーバーといえば、自前でサーバーを立ててリクエストをHTTPで受け取り、DBとやりとりして最終的にレスポンスを返すものが基本だ。これを最新のAWS技術を使えば、必要なくなる時代が来るのかもしれない。

2 Tier Architecture で必要なのは、Amazon Cognito, Amazon S3, Amazon DynamoDB を中心としたサービスだ。各AWSを容易に扱うための AWS SDK を使って開発することが前提となる。どんなことができるか?

まず Amazon Cognito で各種AWSにアクセスするためのクレデンシャルを得る。Amazon Cognito にて、S3 や Dynamo DBにブラウザやアプリからアクセスするための権限をIAMで設定し、それとひも付けたCognito ID を取得する。CognitoID通じて直接各種AWSにアクセスすることが可能となる。

AWS SDKを利用してユーザー共通のDBをそれぞれのクライアントからCRUD操作できたり、画像アップロードなどが簡単に行える。DBを軽く扱うだけのサービスならこれだけでAPIサーバ不要なサービスを構築することができる。自分の認識では以上が 2 Tier Architecture と呼ばれるものだと認識している。

もちろんちょっと踏み込んだサービスなら、サーバ側で処理させるといったことも必要になってくると思う。そんな時に出てくる大注目のサービス、 Amazon Lambda がある。

Amazon Lambda

去年からちょいちょい話題になっているAmazon Lambda、何ができるかというと、

  • 各種AWS(S3, Cognito, Kinesiss, DynamoDBなど)のイベントを受け取り、
  • 任意のタイミングに応じて独自の Node.js コードを実行させる

というのが基本。Node.js コードとあるが、もう割となんでもできる。Node.js サーバがあるようなものだ。ライブラリはnpmで取ってきてそれごとアップロードすればOK。コードをS3に置いてそれをLambdaに参照させることも可能とのことだ。Lambda上で他のAWSを呼び出したり、外のAPIを呼び出したりできる。ただ Lambdaファンクションは一度実行したら基本それで終わりなので、データはDynamoDBなどの外部に保存する必要がある。

どんなことができるのか?

  • S3 アップロードを検知して画像をリサイズするLambdaファンクションを呼び出す
  • S3 にテキストをアップロードしたタイミングで管理者にメール送信
  • DynamoDBに入ったデータを適宜取得して、値の整形をする
  • Kinesiss にデータが入ったタイミングでそれらを集計してDynamoDBに保存
  • Cognito にユーザーが登録した時点で通知

などなど。可能性を感じるサービスだ。

ただ、ここまではLambdaの概要を読めば誰でも知ってたこと。ここからが新しい発見だった。 Amazon Lambda はカスタムイベントを登録することができる。何を意味するかというと、API サーバーとしての役割をAmazon Lambda が担うことができるということだ。

モバイルからでもWebからでも、それぞれ任意のタイミングでLambda ファンクションを実行(Invoke)することができる。実行した結果をレスポンスで受け取りたいなら同期処理、送るだけでいいなら非同期処理の二つの実行タイプが用意されている。同期処理にすれば完全にAPIサーバーとして利用出来る。

ちなみに今年の夏、晴れてAmazon LambdaのTokyoリージョンが開設されるらしい。これにより、S3でtokyoリージョンで運用していたサービスもLambdaを利用することができるようになる。

Lambdaを利用するメリット

  • サーバーを構築する必要がない
  • スケールを考慮する必要がない
  • コードが動いた時間分だけの課金なのでお得。しかも無料枠つき
  • Android, iOS, JavaScriptAWS SDKによりネットワーク処理を簡単に記述できる
  • 今までリクエスト受けたらキューに溜めてたような処理をLambdaに肩代わりさせられる

感じたデメリット

  • デバッグがいまのとこ面倒(アップロードして、Amazon CroudWatch で見る、実際に送ってレスポンスを見るなどくらい)
  • Node.js しかサポートしてない (今後Javaが出るみたい?順次対応予定の模様)

今後の新しい開発スタイル

ちょっとしたWebサービスならS3にHTML/CSS/JavaScript/画像を置いて、Amazon Cognito 経由でデータをアップロード。任意のタイミングで Lambdaを動かしてちょっとしたサーバーサイドの実行もさせてDynamoDBにデータを保存。

こんな開発スタイルがもう既にできるし、簡単にできる時代になっている。うまく運用すればサーバーサイドプログラムを持つ動的なWebサービスを超低価格で実現できるようになるだろう。

そんな新しい可能性を感じることのできた、AWS Summit であった。