Gunosy Tech Blog

Gunosy Tech Blogは株式会社Gunosyのエンジニアが知見を共有する技術ブログです。

re:invent 2017に参加してきました!

開発・運用推進部のおおたです。
SREチームに所属していて、普段はパフォーマンス改善やAWSとのインテグレーションツールの開発を担当しています。

re:invent 2017(11/26~12/1)に参加してきましたので、主にServerlessセッションに関してこちらにまとめを書きたいと思います。
Serverlessとは言っても、Lambdaに限らず、DynamoやGlueまで幅広くご紹介したいと思います。

Optimizing Serverless Application Data Tiers With Amazon DynamoDB 10:00@Aria

アマゾンPrimeDayの構成モデルの内容です。
ユーザー情報をKinesisで受けて、Lambdaで関数からDynamoDBへ情報をアップデートする構成です。
弊社のアプリのニュースパスでも、Kinesis->Lambdaの構成はユーザログを中心に使っています。

Dynamoに入れた情報をLambda経由で、S3,Lambda,DynamoDBへ置いてそれを分析するイメージです。
TTLを上手く使い、古いデータはS3に置くなどしてDynamoDB上には新しいデータだけを配置しています。
ただし、これをやるには手前にあるKinesisはスケールしないので、ユーザ数の増加に合わせてシャードを増やす必要があるとのことです。
その他のLambdaのThroughputはShardに合わせてスケールし、Dynamoもスループットに合わせてスケールします。
DynamoDBについては、構造とアクセスパターン、書き込みなどを最適化するようにするといいとのことです。

続いてCapital One Bankの例。アメリカでは10個の大きい銀行に入り、45百万の顧客がいるとのことです。
スピード、データの量、データのセキュリティでAWSを選んだとのことです。
バッチの部分を3階層のLambdaに分けて最後にDynamoDBに書き込みしています。

ベストプラクティスとしては、データをよく知ること、スケールのテストをすること、アクセスパターンを知る、VPCエンドポイントを使う、暗号化をする、Lamdaのコンテナ再利用をするとのことでした。

How We built a Mission-Critical Serverless File Processing Pipeline for over 100 Million Photos 14:30@Aria

ExpediaのHomeAwayという避暑地の宿泊サービス(190ヵ国!)をServerlessにした例です。
S3,Lambda,DynamoDB,Kinesisを使用して実現しています。
もともと9年前にJavaで書かれたアプリで、NFSのストレージに保管していたのをAWSに移行。

HomeAwayで使われている写真のサイズを変えて保存するシステムの説明です。
AWSにして、アプリがLambdaのおかげでスケールする、S3によってストレージコストが下がる、DynamoDBのメタデータが扱いやすい、マルチリージョンで高い可用性を保てるとのことです。

筆者も昔高いストレージを運用していたのでS3を利用するようになってコスト(と運用!)がかからなくなった点は非常にわかります。
X-Rayでのユニットテスト、Dead Letter Queueの監視もするといいと書いてありますが、Dead Letter Queueがあると異変に気づきやすいので良いと思います。

Severless Authentication And Authorization 13:30@Aria


APIGatewayとLambdaを使ったServerless API

これに加えて、Serverless AppでID管理をするために、Cognito User Pool、Cognito Fedelated Identieies,IAMを使います。
サインインはソルトを使ったハッシュで管理するのがベスト、またはSRP(セキュアリモートパスワード)を使います。

ここのDemoにおいても、API Gateway=>Lambda=>Dynamoの黄金パターンの登場。それらにCognitoを挟むだけになります。
ただし、API GatewayのPOST/DELETEなどのアクションはAdminRoleだけにすることです。
3つの認証方法のやり方について解説されています。
ニュースパスでは、Federated Identitiesを使ってまさにこのやり方で行っています!

ちなみにこのSessionのDemoアプリに関してはGitHubにあります。 https://github.com/awslabs/aws-serverless-auth-reference-app

Multi Region Serverless 17:30@Aria

まだ筆者が担当のサービスはマルチマスターを使用していないので、興味深いと思い、聞いてみました。

マルチチージョンでのAPI GatewayのRoute53を利用して実現します。
マルチマスターだと大変さもある。マルチリージョンのACIDトランザクションは非現実的とのことです。
書き込みは常にマスターリージョンで、読み込みはそれ以外のリージョンですること。
マルチチージョンでもログは1箇所(片方)にまとめます。

Serverless Application Model(SAM)があり、CloudFormationはServerlessに最適化されています。
http://github.com/aws/labs/serverless-application-modelにも詳細があります。

さらに、ここにAWS CodePipelineを組み合わせるとより効力があります。(codecommit,codebuild,cloudformation,SAM)
マルチリージョンの構成は複雑になるので注意深くやるべきとのことです。
マスター/マスター構成のレプリケーションは、複雑になり、顧客体験もよくないのでシンプルにやるべきとのことです。


Route53を使用すればfailoverチェックが行われるが、メトリクスやアラームは仕掛けるべきとのことです。

Serverless ETL With AWS Glue 14:15@Aria

4 stepでできるETLの紹介です。
s3=>AWS Glue Crawler=> AwS Glue Data Catalog=>Athena/EMR/Redshift Spectrum<= BI Toolで分析。

使っている顧客にはNTT Docomo, Expedia,有名な車の会社などがあります。
スキーマ変更、データソースの変更、データボリュームの増加、フォーマットの変更をコードで対応できます。
パフォーマンスについては、Year, Month, Dayであった時に、ファイルサイズが小さい方がパフォーマンスは出るとのことです。

10DPU,Spark2.1.1でJson=>CSV変換でやった時の結果で差があります。 同じことをSparkとGlueでやると、Sparkは640KファイルでOOMになり、Glueは1.2Millionファイルまでできたとのことです。
(Crawlerの1タスクにつき自動にグループされたファイル)

またDevEndpoint機能でZeppelinが使え、pysparkコードを書いていきます。
Glue transforms:
toDF()
Spigot()
Unbox()
Filter(),Map()
Join()など

近々、Scalaがサポートされ、新たなリージョンとして東京(!!!)とアイルランドで使えるとのことです。

残りの時間で質疑応答がありました。
- Jobが遅いのはDPUを増やしてほしい。
- EMRとの違いは、EMRはmanagedであり、serverlessでない。Glueはそれに比べてオペレーションが少ない。 EMRはHadoopエコシステムの1つの位置づけ。

Deploying Machine Lerarning Models of AWS Services, AWS EMR , Batch, Lambda 8:30@Venetian

EMR(Spark)でのDeploy,Batch Deploy,ECS Deployの方法について、App Developper,App Engineerの登場人物を含めたやり方の解説でした。
Chalk Talkなのでセッションの半分は質疑応答中心でした。

ここでもDepoloyはCodeBuildを使ったやり方が推奨されていました。
この図でもわかるように、使い分けが重要です。

感想

今回、初めての参加でしたが、遊び心があるイベントでまた機会があれば参加してみたいと思いました。
特に日本のイベントにはないような、DJやライブを挟んだりする構成は観客をひきつけてやまなく、非常に興味深く感じました。

re:Playの様子です。

今回、参加して感じたことは、Serverlessの流れは、サーバーに止まらず、機械学習やETLにまで発展してきているということで、それらを上手く組み合わせて利用するのが重要だと感じました。

また、特にこちらでは触れませんでしたが、KeynoteにもあったようにAWSは今後も省力化、セキュリティ、インターフェースには注力していくとのことで、この流れはサービス全体にも広がりそうです。

まだ一部しかアップデートが来ておらず、東京リージョンでは使えない新サービスもありますが、出てきたらまた弊社の事例などをご紹介したいと思います。

最後に、そんなAWSの新しいサービスを使って開発したい、使いこなしたいSRE・サーバサイドエンジニアを絶賛募集中です!ご応募ください!

https://hrmos.co/pages/1009778707507720193/jobs/0000007hrmos.co

https://hrmos.co/pages/1009778707507720193/jobs/0000003hrmos.co