AWS DevDay Tokyo 2018というイベントを開催します!

タイトルの通りです。Amazon Web Services Japan主催で『AWS DevDay Tokyo 2018』というものが10月29日(月)〜11月2日(金)まで一週間に渡って開催されます。場所は目黒の駅前にあるAWSJオフィスが入っている目黒セントラルスクエアというビルです。

aws.amazon.com

このイベントに自分は主に企画・コンテンツといった内容面で深く携わっているので今回はそのあたりを少しご紹介します。ちなみにどうでもいい情報ですが今回、僕は裏方に徹しているので自分のセッションはありません。

イベントの狙い

狙いというほどのものでもないですが、本イベントは毎年6月くらいに開催しているAWS Summit Tokyoという年次イベントの併催という形で昨年は開催されたものです。ちなみに開発者向けのイベント自体は2015年のAWS Summit Tokyoの新しい試みとして開催されたのが最初でした。このときの企画にも携わっていて、新しいことをやる楽しさはあるもののそれなりに大変だったのはいい思い出です。このときはイベント当日に向けて翔泳社Codezineとタイアップした連載企画などいくつかの企画を走らせていました。この初回の収録日直前に妻が急遽入院してしまいまだ2歳にもなっていなかった娘とわちゃわちゃしてたのはいい思い出です。

そんな話はともかく、デベロッパーカンファレンス(DevCon、2015)→Developers Conference(2016)→DevDay(2017)と各年で装いとかイベントタイトルなどに微細な変更はあったもののAWS Summit Tokyoとの併催という形で開発者向けカンファレンスは開催されていました。自分が企画として関わったのは2015年のもので2016年は登壇者として、2017年はDevDayの3日目を『Serverless Evolution Day』と名付けてサーバーレスにフォーカスした建付けにしました。以下はそのときのまとめです。

www.keisuke69.net

とまあ、こんな感じで毎年なんらかの形で携わってきました。しかし、今年はAWS Summit Tokyoにそういったものがなかったのは来場された方であればご存知かと思います。実際に何人かの方には今年はないのかというご意見もいただきました。実はこの時点で秋に単独で開催することは決まっており、企画についても検討が始まっていました。本当はこの時点でなんらかのアナウンスができていればよかったんですが諸事情でできませんでした。

実際に対外的に最初にアナウンスをしたのは7月8日に開催された『HTML5 APP CONFERENCE 2018』で自分が登壇した際になります。そんなAWS DevDayですが装いも新たに単独イベントとして帰ってきます。狙いはずばり、『アプリケーション開発者のためのカンファレンス』です。実のところAWSはインフラ寄りな勉強会とか自習用の各種マテリアルは結構揃っているんですが、普段アプリ開発者の人と会話していると結構知られていなかったり、情報集めに苦労されているという話を聞いています。というわけで今回はAWSを取り巻くアプリ開発者をターゲットに、より実践的な知見、知識を持ち帰ってもらうことを主眼においています。加えてAWSに関する話だけでなく、モダンなアプリケーション開発をする上で知っておくといいこと、トレンドなど直接的にAWSに関係ないジェネラルな内容も積極的に盛り込んで行くという方針でトラックおよびセッションの企画を行っています。また、『実践的な知見、知識を持ち帰ってもらう』というコンセプトからハンズオンやワークショップもたくさん用意しています。

用意されるプログラム

5日間中に用意されるプログラムは多岐にわたります。

  • Dev AWSome Day (10/30)
  • AWS Solution ハンズオン (10/30)
  • テクニカルセッション (10/31〜11/2)
  • AWS Game Solution ハンズオン (10/31〜11/1)
  • Amazon Alexa Skill 開発ハンズオン (10/31〜11/1)
  • Dev Day Challenge (11/2)

さらにこれら本編とは別に10/31の夜にはLT大会、11/2の夜にはAfter Partyが開催されます。

Dev AWSome Dayと各種ハンズオン

Dev AWSome Day

今年のAWS Summit Tokyoでも好評だった各種マネージド・サービスを使ってアプリケーション開発を行う方法をハンズオン形式で学ぶ開発者のためのトレーニングイベントです。こちらはサーバレスアーキテクチャの概念を理解した上で、簡易なサービスを実際に AWS 上で開発するものになるのですが、AWSのスキルや経験は必要ありません(アプリ開発経験は必要ですが)。

AWS Solutionハンズオン

用意されているハンズオンも非常に多岐に渡ります。機械学習プラットフォームとして注目を集めるAmazon SageMakerだったり、機械学習をベースとした各種APIサービスを活用したアプリケーションの開発、DevOps、GraphQLのマネージド・サービスであるAWS AppSyncを活用したモバイルアプリ開発Amazon DynamoDBを利用したアプリケーション開発入門、そしてセキュリティサービスを活用してAWS環境における脅威検知と対応を実践するワークショップが用意されています。さらにはIoTに関するハンズオンもレベルに応じて複数回開催される予定です。

Game Solutionハンズオン

皆さん、GameSparksってご存知ですか?

f:id:Keisuke69:20181015144308p:plain

GameSparksは昨年Amazonが買収したゲーム向けのバックエンドサービスです。オンラインゲームに必要なコンポーネントをゲームの一部としてすぐに実装できるというものですが、今回は代表的なゲームコンポーネントであるチャットやリーダボードなどの実装についてハンズオン形式で体験できます。

そして、ゲームといえばもう一つ、AmazonにはTwitchというゲーム配信プラットフォームがあるのをご存知でしょうか?

www.twitch.tv

このTwitchが提供するAPIを用いて、動画内にゲームの状況や投票パネル等を表示して配信者と視聴者へインタラクティブな体験を提供できます。それを体験するワークショップが用意されています。しかもそれぞれ3日間、計3回あります。

Amazon Alexa Skill 開発ハンズオン

Amazon Alexaのスキル開発をする方向けに『はじめてのAlexaスキル』、『Alexaハンズオントレーニング(初級)』、『Alexaハンズオントレーニング(中級)』が2回ずつ開催されます。 

セッション

セッションは10/31〜11/2の3日間に渡って各日2トラック構成で開催されます。詳細は公式サイトのタイムテーブルを参照していただきたいのですが、以下のようなトラックを用意しています。

  • Software Design
  • Serverless/Mobile
  • Machine Learning
  • Database
  • Microservices
  • Startup Technology

特にお伝えしたいこととして、今回はアプリケーション開発者向けのカンファレンスだと前述しました。というわけで各トラックも通常のAWSサービスに関するセッションというよりも開発に寄せた話をしていく予定です。例えばデータベースなんかであればサーバーレスとあわせてよくご相談をいただくことが多いNoSQLデータベースのAmazon DynamoDBのデザインに関する話などを予定しています。もちろん事例としてお客様にもご登壇いただきますし、今回はCFPによる公募セッションもいくつか用意されています。

個人的に一番お伝えしたいのはSoftware DesignとMicroservicesトラックです。

Software Designトラック

このトラックではよりGeneralなアプリケーション開発の話が聞けるのではないかと思います。『体系的に学ぶ 安全なWebアプリケーションの作り方』でお馴染みの徳丸先生によるセッションやChatworkかとじゅんさんによるDDDのお話、t-wadaこと和田卓人氏によるコンポーネントが分散した環境でのテストの話など盛りだくさんです!また、少し変わったところでいくと昨今、デベロッパーといえど勉強会やいろんなイベントで登壇する機会も増えていますし、個人の価値を高めていくにもそういった機会を活かしてプレゼンスを高めていくことも重要だと考えています。でも、不慣れだとプレゼン資料作ったりするのって大変ですよね?そんな方にはぜひ長沢さんのセッションを聞いて欲しいです。きっと参考になるトピックがいっぱいかと。あとはモバイル界隈での注目トピックといえばPWA(Progressive Web App)がありますが、話題にはなっているもののなかなかまだその具体的な事例や知見を目にする機会って少ないといえます。そこで日経の安田さんに日経電子版でのPWA事例についてお話いただきます。

Microservicesトラック

皆さんそろそろ『Microserviceとは?』みたいな話って食傷気味じゃないですか?ということで一歩踏み込んでMicroserviceやるにあたってより具体的で実践的な知見を得てもらうことをテーマにセッションを考えました。まずマイクロサービス化するにあたってのデザインパターンをグロースエクスパートナーズの鈴木さんにお話頂いたあと、より具体的な手法やテーマを掘り下げていきます。具体的にはMicroserviceの文脈で頻出するEvent SourcingおよびCQRSの具体的な実装に関するお話をアイスタイルCTOの竹澤さんより、これまたサービス間の認証認可、権限委譲をどうするかっていうあるあるな悩み事に関する話をクラスメソッドの都元さんに話してもらいます。そして、もう一歩踏み込んだときに話題になるBFF(Backend For Frontend)およびMicro Frontendの話をそれぞれ古川さんとFincの澤井さんに事例をもってお話しいただけます。古川さんといえばNode学園などNode.js界隈での超がつく第一人者でもありますね!

そしてMicroserviceといえばトラックこそStartup Technologyトラックですがそちらで、メルカリ内田さんによるMicroserviceならびにMicroserviceと切り離せないトピックであるコンテナについてお話いただきます。さらに熱いのがその流れで行われるパネルディスカッションです!内田さんに加えて、クックパッドの星さん、サイバーエージェント青山さん、freeeの九岡さんとコンテナ関連での業界キーマンたちによるパネルディスカッションを時間を少し延長して行います。 

DevDay Challenge  

さて、もう一つお伝えしたいのがこのDevDay Challengeです。今これを読んでいるあなたがサーバーレス関連コミュニティに顔を出していたり、9月末に開催されたServerlessconfに参加した人であれば聞き覚えのあるタイトルかと思います。このイベントは当日、その場で運営から提示されるお題に従って1日でアプリケーションを実装し、そのアーキテクチャ、完成度などを軸に優勝者を決めるというイベントになります。まあ要はハッカソンの変形ですね。Serverlessconfで開催されているものと異なるのはサーバーレスという技術要素を前提としないことです。より柔軟な技術選択が可能になるということですね。とはいえこのイベントはDevDayです。アプリ開発者のためのカンファレンスです。そのあたりを少し意識して挑んでもらえればと思います。ちなみにチーム戦ですが1人チームもOKです。とはいえUI必須なので時間内で完成させるにはフロント、バックエンドと分かれていたほうがいいかも知れません。また、一人で応募して運営側にチーム分けを任せるということも可能です。

参加者はこのあとのAfter Partyでピッチしてもらい、優秀チームには豪華(!?)景品も進呈予定です。

Office Hour

さて、コンテンツは以上となるのですがそれ以外にもいくつかあります。まずはOffice Hourです。期間中AWSのSAによる個別相談会が開催されます。こちらでは実案件に関する技術的な相談を行えるようになっています。ガチな本番案件とかWelcomeなのでぜひこの機会にご活用いただければと思います。

LT大会

こちらは先だって募集をしたLT大会になります。10/31の夜に採択された方たちによるLTを見ながらのパーティとなります。

最後に

今年初めて単独で開催されるAWS DevDay Tokyoの見どころのごく一部をかいつまんでご紹介しました。もちろん無料で開催されますので参加するしかないのではないでしょうか。

ただ残念ながら上でご紹介したもののうちいくつかは既に満席となっています。そんなあなたに朗報です。仮に満席となっていても当日待機列に並んでもらえれば空きがあり次第参加可能です。また、ライブストリーミングも予定していますので当日会場に来れない方もぜひそちらで参加していただければと思います。ライブストリーミングについては詳細が決まり次第別途ご案内を行います。

というわけで当日は目黒の会場にて皆さんをお待ちしています!ご登録はお早めに!

aws.amazon.com

『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』という本を書きました

かなり久しぶりの更新ですが、タイトルの通り『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』という書籍を執筆し3月16日より発売されましたー。

出版社はマイナビ出版さんで、もちろんAmazonで買えます! 

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

 

目次は以下のようになっています。総ページ数は297ページと前回(263ページ)をわずかに上回る分量となりました!

Chapter1 サーバーレスアプリケーションの概要
1-1 サーバーレスアプリケーションとは
1-2 ユースケースアーキテクチャパターン
1-3 サーバーレスアプリケーションのライフサイクル管理概要

Chapter2 Amazon Web ServicesAWS)利用の準備
2-1 AWSアカウントの取得
2-2 AWSにおける認証と認可について
2-3 リージョンの選択
2-4 AWS Command Line Interface(AWS CLI)の準備

Chapter3 インフラを自動化しよう
3-1 Amazon CloudWatchのアラームをトリガーに自動処理をする
3-2 Webサイトの状態を定期的にチェックする

Chapter4 Twitterのリアルタイム分析をしよう
4-1 Amazon Kinesisを使ってTwitterのデータを受け取る
4-2 AWS Lambdaを使ってストリーミングデータをAmazon DynamoDBへ保存する

Chapter5 写真投稿サイトをシングルページアプリケーションで作ろう
5-1 Webサイトの概要を確認する
5-2 バックエンドのAPIを実装する
5-3 フロントエンドを実装する
5-4 Amazon Cognitoを利用した認証処理を追加する
5-5 Amazon Rekognitionを使って自動タグづけを行う

Chapter6 サーバーレスアプリケーションのライフサイクル管理
6-1 AWS Serverless Application Model(AWS SAM)詳細
6-2 複数環境の管理
6-3 デリバリプロセスの自動化(CI/CD)

Chapter7 サーバーレスアプリケーションのトラブルシューティング
7-1 メトリクスのモニタリング
7-2 AWS X-Rayを利用したトラブルシューティング

 

 

さて、今回の書籍執筆にあたりいくつかの試みがありました。まず、昨年のAWS Summit Tokyo 2017のタイミングで『実践AWS Lambda』という本を書いて発売されたのですが、このときのポストにも書いたようにいくつかの点で心残りがありました。 

また、スクリーンショットに関しては今回は主に初心者向けということでなるべくマネージメントコンソールからの操作にしようという方針だったので、スクリーンショット多めだったんですが、次回からは全てCLIを使った手順にしようと強く思いました。CLIベースであれば画面のアップデートによる影響を受けないので。

なかでもこのスクリーンショットによる手順の問題はずっと気になっていた点です。というのもロードマップ情報を知る立場として、対外的には言えないもののAWS Lambdaのコンソールがアップデートされることを実は知っていたのです。ただし、執筆中に聞いていた範囲ではそこまで大きなものではないはずでした。しかし、実際にAWS re:Invent 2017で発表され、その大きく様変わりしたユーザーインターフェースに驚いた方も多いと思います。これだけ大幅な変更が入ることがわかったのは脱稿した後でしてどうしようもなかったというのが実情です。

実際のところ、このマネージメントコンソールのアップデートで既存資料が影響を受けるというのはあるある話なんですね。例えば、前日夜中までかけてハンズオン資料作って、翌日いざってときに画面が変わってるとか。

しかし、『実践AWS Lambda』に関しては6月に発売開始され、マネージメントコンソールのアップデートが発表されるのが11月末でした。言ってみれば賞味期限として半年程度しかないことになります。

書籍の場合、機能のアップデートが多いと追従できず陳腐化しがちという課題もあるのですが、コンソールのアップデートというのはまた違います。今回のように大幅な変更が入ってしまうと解説している手順自体が変わってしまうわけです。というわけで前回の書籍でやりたくてもスケジュール上の問題でできなかったCLIによる手順を今回の手順では全面的に採用しています。

その結果、スクリーンショットが少なく初心者の方には少し手が出しづらいものになってしまったかも知れません。その点に関しては申し訳ないと思うものの情報の賞味期限を延ばすためでありご理解いただけると嬉しいです。

また、ほとんどの手順をCLIで解説したことで発生した課題もあります。それは1つのコマンドが非常に長いものが多く紙面サイズ上一行で掲載できないのはもちろん複数行にわけるにしてもキリの良いところで改行できないというなかなか悩ましい問題がありました。なるだけ対応したつもりではありますが、わかりにくい箇所があるかもしれません。

 

さて、それ以外では前回は主にAWS Lambdaの機能や設定項目について解説した内容となっていたのですが、実際のところAWS Lambdaを中心とする「サーバーレス」なサービスを活用して構築する「サーバーレスアプリケーション」では各サービスの設定方法だけでなく、実際にアプリケーションからどう呼び出すかがイメージし辛いという声をよく聞いていました。そこで、今回は企画段階からユースケース別に実際のアプリケーションをサンプルとしてコードベースで解説するというものにしようという話になりました。そのかわり各サービスの機能や設定方法の詳細に関してはそこまで言及せず、あくまで組み合わせや選択時における考え方を示すだけにしようというのが本書のコンセプトでした。そこで実際のよくあるワークロード、ユースケースをもとにサンプルとなるアプリケーションを用意していきました。

とはいえ、ページ数やスケジュールの都合で盛り込めなかったものが多いのも事実でした。本当はテストに関しても深掘りしたかったところです。考え方はコンテキストの違いによってもいろいろあるものの1つの考え方を示したいという思いがあったのですがこちらに関しては残念ながら見送りました。また、シングルページアプリケーションの章において実画像の削除処理をAmazon DynamoDBのストリームをもちいて非同期で行うというものを盛り込みたかったのですがこちらに関してはページ数の都合で割愛となってしまったことは残念です。とはいえ、触れるべき内容ではあるのでこちらの処理に関してはサポートサイトにて別途配信を予定しています。

それ以外にも、例えばAWS LambdaでDead Letter Queueを用いてより信頼性・堅牢性の高いアプリケーションをしていく話やAWS Step FunctionsとAWS Lambdaを用いた分散バッチ処理実装やLambdaファンクションのオーケストレーションといった部分も色んな事情が重なって含めることができませんでした。まあ色んな事情の多くはスケジュール的なものだったりするのですが。

 

なお、今回ももちろんサポートサイトが用意されています。

book.mynavi.jp

 

こちらのサイトでは本文に含まれているソースコードが全てダウンロードできるようになっています。正直なところ、本文に記載されているコードを全て手で写して実行するのはかなり大変な作業になると思いますのでダウンロードして活用いただければと思います。

また、今後発見されたミスや誤字などの修正に関しても随時こちらのサイトに記載されていきます。
※既にいくつかご指摘いただいています…m(_ _)m

 

あと、発売を記念して購入者限定のセミナーをマイナビさん主催で開催することになっています。購入した方であれば無料で参加できますのでぜひお越しいただければと思います。当日は私のほうからはサーバーレス関連サービスのアップデートならびに最新事例のご紹介を行います。また、別のものがサーバーレスアプリケーションのライブコーディングをお見せすることも予定されています。

もちろん、私がいるので本の内容に関する不明点などを直接ご質問いただいても構いませんし、感想などをいただけると非常に励みになります。

また、当日は来場の方向けに特製AWS Lambda Tシャツを御用意していますのでお時間がありましたらぜひお越しいただければと思います。

お申込みは以下のサイトよりどうぞ。

2018年3月発売予定『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』で、ご予約・ご購入者限定イベントを開催します! | マイナビブックス

 

なお、『実践AWS Lambda』に関しては現在改訂版を準備中でして、発売以降のアップデートを盛り込むだけでなく手順をすべてCLI化します。こちらは順調にいけば今年のAWS Summit Tokyoあたりでお届けできるのではないかと思っております。

 

最後に、技術書に関する今後の在り方について個人的に思うところをつらつらと書いて終わりにします。今回の書籍は執筆時間がなかなか取れずダラダラと期間をかけてしまったのですが、そこに年に一度のグローバルカンファレンスであるAWS re:Inventが重なっていたこともあり紹介しているサービス群にもいくつかアップデートが入っていたりします。今回は各サービスの深掘りではなく組み合わせとアプリ実装に重きを置いていたのでAWS Lambdaのマネージメントコンソールの問題以外は大きな影響はなかったものの、やはりクラウドのような進化の速いサービス・プロダクトに関する解説書というのは難しいなと強く感じたのも事実です。電子版はアップデートしやすいのでまだしも紙の書籍に関しては特にそう思います。

一方で技術書の類はどういうわけか事実として紙媒体のほうが好まれます。また、公式のドキュメントではわかりにくいところがあるのも事実だと思います。特に英語のドキュメントを翻訳しているものなどは日本語表現としてわかりにくいことも往々にしてあります。

そういったこともあり、日本語執筆者による解説書の有用性は認めるものの、先述したとおり機能のアップデートが早く、多いとそれに対して紙媒体では追従が難しく陳腐化しがちというのは作者としてはそれなりの苦労をもって書いている以上悲しい気分にもなったりするわけです。

もちろんすべての技術書が同様とは思いません。長期に渡って手に取られる優れた技術書というのも数多く存在します。特定のサービスやプロダクトについて解説するものだからそういうことに陥りがちというのもわかります。

と、まあこんな感じでモヤモヤした気持ちを抱えたまま答えも出ずに過ごしていますw

 

というわけで、とりとめもなく書いてしまいましたが、各種勉強会での登壇依頼もお待ちしていますので、こんな私でよければTwitterあたりで雑に絡んでいただけますと幸いです。

 

ブログ分けました

 

というわけでブログをわけました。

テックぽいこと、お仕事絡みのことはこれまで通りのブログでそれ以外は新しく立ち上げたブログで更新していきます。

 

理由はいろいろあるけどまあ仕方ない。

というわけであんまり更新ないですが今後ともよろしくお願いします。

 

なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する

f:id:Keisuke69:20170621131534j:plain

表題の通りです。
AWS LambdaとRDBMS全般(Amazon RDSに限らず)はその特性的に相性が悪いのでデータストアはなるべくAmazon DynamoDBを使いましょうという話しをよくします。
今回はなぜそうなのかをもう少しだけ説明しようと思います。

大前提

まず、大前提としてAWS Lambdaは水平方向へのスケーラビリティを特徴とするサービスです。リクエストが来たらそれを処理するLambdaファンクションのコンテナを作成し、処理を実行します。

このLambdaファンクションのコンテナは1つあたり同時に1リクエスト(1イベント)しか処理しません。従って同時に100リクエスト来た場合は同じLambdaファンクションのコンテナ100個で処理されます。ただし、必ずしも毎回100コンテナが1から作成されて起動されるわけではありません。

Lambdaファンクションのコンテナは起動コストの効率化のために再利用も行います。いわゆるウォームスタートというものですね。ウォームスタート可能なコンテナがあれば新しくコンテナを作ることはせずにそれを利用します。しかし、ウォームスタートできるコンテナがない場合やあってもその数以上のリクエストを同時に処理する必要が発生した場合は新しくコンテナが作成・起動されます。これがデフォルトの同時実行1000だと1,000コンテナが同時に実行される可能性があるわけです。もちろん10,000であれば10,000個です。とはいえ、AWS Lambdaを中心とするサーバレスのプラットフォームはNever Pay for Idleなのでリクエストがなければ一切費用は発生しません。

最大同時接続数の問題

ご存知の通り各種RDBMSには最大同時接続数的なパラメータがあるわけですが、設定可能な値と実際に使い物になる値は別物です。DBエンジンごとの多少の違いはもちろんあるものの、使い物になる数値というのはCPU数やメモリ数と大きく関係してきます。

当然ながら同時に接続される数が多ければ多いほど必要なCPU数、メモリ数が増えていきます。つまり、アクティブな接続が同時に数千から数万になるDBを動かすにはそれなりのスペックが必要というわけです。そもそもプロセスやスレッドが数千とか数万になってくると1サーバのOSだとコンテキストスイッチやら何やら厳しくなってくるので、DB分割なんかも検討するかと思います。

また、RDBMSというと、現状ではほとんどが処理量が増えた場合にスケールアウトで対応するのではなくスケールアップが必要になります。要はサーバに積むCPU、メモリなどを増やす方向です。参照系はスケールアウトできても更新系はスケールアップで対応するしかないことが多いです。

さて、ポイントは先のLambdaファンクションの振る舞いとの兼ね合いです。まず、説明のとおり、リクエストがあるとコンテナが作られて起動されるのでこのタイミングでDBへのコネクションが張るわけですが、リクエストのたびに接続するのはコストがかかるので、その接続オーバーヘッドを減らすための方法として、グローバルスコープを利用することでコンテナがアクティブな間、つまりウォームスタートの場合はそれを利用するという方法があります。

一方で先ほどの説明の通り、Lambdaは同時に処理すべきリクエストは必要なリクエスト数分のコンテナで処理します。つまり、各コンテナからDBへとそれぞれコネクションが張られることになります。ということは仮にデフォルト状態であっても1000コネクションが張られる可能性があるということです。これがプロダクション環境でもう少し大きいシステムであれば数千同時実行 = 数千コネクションとかにになってきます。こうなってくると一般的にはコネクションプールを使うことが多いと思います。DBへ都度接続するコストを減らした上で、コネクションを使いまわすことで負荷を減らすわけです。

ところが、Lambdaではこのコネクションプールを実現することが難しいのです。Lambdaファンクションのコンテナ間では何も共有しませんし、外部のデータストアへと永続化しない限りはできないからです。つまり、コンテナをまたいで利用するようなコネクションプールの実装は難しいと言えます。それを管理する中間層のようなものを用意して各コンテナはそれ経由でDBにアクセスするような何かを作るとかして頑張ればなんとかなるかも知れませんが、ちゃんと検討したことないのでわかりません。

話しを戻すと、このようなLambdaファンクションのプラットフォーム特性を考えるとダウンストリームとなるシステムも同様にスケールアウトするようなものでないと耐えきれないです。同時実行数が少ないうちはいいですが増えてくると耐えられなくなってきます。実はこれはRDBMSに限らない話しなんですけどね。スケールアウトできないシステムの場合、ある程度まではピークにあわせたスペックのサーバを用意しておくことで対応できるとは思いますが、限界は来るかと思います。また、せっかくNever pay for idleを特徴とするプラットフォームを利用するにも関わらず、ピークのために通常よりも巨大なスペックのDBサーバを維持するのももったいない話しですしね。

というわけでLambdaと組み合わせて利用するデータストアとしてはDynamoDBを推奨しているわけです。DynamoDBの場合は分散型データベースであり同時接続数の増加そのものは気にする必要がなくなります。また、一貫して高速で安定したパフォーマンスを得られます。もちろんスループット増に伴ってコストは発生しますが、そもそも対応できないという状況はなくなります。

VPCアクセスのレイテンシコスト問題

これはRDBMSに限らない話しなのですがLambdaファンクションがVPC内のリソースにアクセスしようとしたとき、かつコールドスタートが発生したときはその仕組み上10秒〜30秒ほどのレイテンシが上乗せされます。いくらコールドスタートの発生頻度が低いとはいえ、ゼロにすることはできないです。

一方で、RDBMSVPCの中に置くことが多いと思います。そうするとこのレイテンシの考慮が必要になってきます。ここはシステムの要件次第なので一概には言えないですが、DBアクセスを伴う処理がたまにとは言え10秒を超えてくることを許容できるかどうかです。

まとめ

LambdaとRDBMSの組み合わせをあまり推奨しない理由を2つ挙げました。
もちろんそれほど同時実行されることがないのであれば最初の問題はほとんど関係ないかも知れません。また、たまに発生する10秒を超える実行時間が問題ない場合もあるでしょう。

逆に言うとそうでない限り、LambdaとRDBMSを組み合わせて利用するのは止めたほうがいいです。すべてのLambdaファンクションがRDBMSに接続する必要がないのであればDynamoDBも併用してRDBMSの利用は必要最低限にするのもありですし、処理によってはLambdaファンクションのアクセス先はあくまでもDynamoDBにしてストリームを使って非同期にRDBMSに反映するという方法が取れるかも知れません。

このあたりはケースバイケースなので必要であればご相談ください。

 

最後にしつこいくらいに自分の本を宣伝しておきますね。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

 

  

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド