ブログ分けました

 

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

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

 

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

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

 

広告を非表示にする

なぜ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 ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

 

 

AWS Summit Tokyo 2017でのサーバレス関連セッションまとめ

(06/21アップデート:Game Tech Sessionのスライドを追加しました)

2017年5月30日〜6月2日までの4日間で開催されたAWS Summit Tokyo 2017ではとても多くのセッションが提供されたわけだけど、その中からサーバレス関連のセッションだけをピックアップして資料のダウンロード先をまとめます。ちなみに今年のAWS SummitではDevDayという開発者向けのイベントも併催されていて、その最終日はさらにServerless Evolution Dayというタイトルでサーバレス関連セッションばかりを集めていたけど、それに対して普通の方(ひとまず本編と呼ぶ)でもいくつかサーバレス関連セッションがあったのでそちらも拾ってます。

なお、SlideshareやSpeakedeckで公開されていればそちらを埋め込み、本家サイトでの公開のみの場合は資料リンクを貼っておきます。 

【Day 2】2017 年 5 月 31 日(水)

Going Serverless with AWS

AWSのサーバレス関連のプリンシパルプロダクトマネージャであるAjay Nairのセッション。プリンシパルってのはプリンシパル>シニア>無印な感じです。なお、途中でCanonの八木田さんも事例として登壇頂いてます。

資料なんですが、このちょっとした手違いでまだ公開されていないので公開され次第掲載します。今は表紙スライドのスクショだけでご容赦を。資料が公開されたのでリンクを追加しました!

 

f:id:Keisuke69:20170616180500p:plain

 資料リンク

教えて!中堅企業の事例に学ぶ AWS 活用サクセスストーリー

これはサーバレスが中心のセッションではないんですが、最初のお客様の事例でAmazon RekognitionとAWS Lambda、Amazon API Gatewayなどを組み合わせた顔検索機能の話しが出てきます。

 

f:id:Keisuke69:20170616184746p:plain

資料リンク

 

流通業界におけるデジタルトランスフォーメーションの実践

Amazonの事例でサーバレスの話しが出てきます。サーバレスで実装したことによる実際の効果についても語られています。

 

f:id:Keisuke69:20170616185522p:plain

資料リンク

 

【Day 3】2017 年 6 月 1 日(木)

Day 3 基調講演(キーノート)

Day3のキーノートではAmazonのCTOであるWarnerからテックな話しをいくつかあったんだけど、その中でAWS Lambdaを中心としたサーバレスに関する話しもあります。

 

f:id:Keisuke69:20170616172403p:plain

資料リンク

 

最新 IoT デザインパターン 〜AWS IoT と AWS Greengrass を用いた構築パターン〜

AWS IoTを中心とした話しなんですが、AWS IoTということは当然サーバレスなわけです。Lambdaも出てきますがそれ以外のサーバレスなサービスを組み合わせたIoT向けデザインパターンです。

 

f:id:Keisuke69:20170616190120p:plain

資料リンク

 [朝日放送] サーバレスアーキテクチャで実現した M-1 グランプリ敗者復活戦投票システム

残念ながら資料はまだ公開されていないみたいです。なのでこのセッションのレポート記事のリンクを貼っておきますね。

news.mynavi.jp

資料が公開されたのでこちらもリンクを追加しておきます!

f:id:Keisuke69:20170620140013p:plain

 資料リンク

Speed matters - Amazon Kinesis が実現するストリーミングデータのリアルタイム分析

Kinesisを中心としたストリーミングデータの扱いに関する内容となってます。

 

f:id:Keisuke69:20170616190458p:plain

資料リンク

セイコーエプソンのデータプラットフォームビジネスにおけるサーバレスアーキテクチャへのマイグレーション 

f:id:Keisuke69:20170616173323p:plain

資料リンク

【Day 4】2017 年 6 月 2 日(金)

[ソニーモバイルコミュニケーションズ] スマートホームシステムの開発 〜AWS を活用した新規サービスの立ち上げ〜

Amazon CognitoのUser PoolやAWS IoTならびにAWS Lambdaあたりの話しが出てきます。

 

f:id:Keisuke69:20170616173809p:plain

資料リンク


全部教えます!サーバレスアプリのアンチパターンとチューニング

これは自分のセッションですね。ここではやってしまいがちなパターンとどうすればいいのか、あとはコールドスタート関連について説明しています。

 

speakerdeck.com

[JINS] バイタルデータの意味付けという荒波を乗り越える!適切な処理分担のためのサーバーレスアーキテクチャ

f:id:Keisuke69:20170616183147p:plain

 

資料リンク


サーバレスで王道 Web フレームワークを使う方法

このセッション面白いよ?今まであんまり語られることがなかった内容で、Express.jsとかSpringといった従来からある一般的なフレームワークをサーバレスでも使いたいって人たち向けの解説。既存の移行とかこういったフレームワーク使いたいとかの人たちには必読です。

 

speakerdeck.com


[ワイヤ・アンド・ワイヤレス] AWS Lambda を使ったモバイルバックエンドのサーバレス開発事例

こちらのセッションは残念ながら資料・動画ともに非公開だそうです。


[タワーズ・クエスト]Serverless 時代のテスト戦略

テストの伝道師こと @t-wada さんがサーバレスアプリのテストについて語ってます。みなさんもサーバレスアプリ、特に「Lambdaのテストってどうしたらいいの?」って悩んでる人も多いのでは?そんな方は必読です。

 

speakerdeck.com


[ワークスアプリケーションズ] AWS Lambda で変わるバッチの世界 ~ CPU 時間トータル 100 時間の処理を 10 分で終わらせるには~

このセッションはLambdaの考え方をよく理解して効果的に実装されている例についてお話されてます。とても参考になるノウハウも多いかと。

 

f:id:Keisuke69:20170616183502p:plain

資料リンク


もう悩まない!AWS SAM で始めるサーバーレスアプリケーション開発

みなさん、AWS Serverless Application Model (AWS SAM)って知ってます?サーバレスアプリケーションをパッケージングしたりデプロイするためのAWSの推奨ツールです。推奨も何もAWSオープンソースで作ってるんですけど。そのAWS SAMについて、日本のサーバレスコミュニティの立役者、吉田真吾さんが説明してくれてます。

 

www.slideshare.net


[Sansan] AWS が支える Eight のリコメンデーションエンジンの裏側

Lambdaだけでなく、Step Functionsも活用した興味深い事例です!

 

speakerdeck.com


サーバーレスアプリケーションのための CI/CD パイプライン構築

f:id:Keisuke69:20170616183826p:plain

資料リンク


[日本経済新聞社] 紙面ビューアーとサーバーレスアーキテクチャ

こちらも残念ながらまだ資料が公開されていないようなので公開され次第、リンクを貼りますー。レポート記事なんかも見つからなかったです。

セッション内容とは関係ないんですが、日経さんと言えばAWS Summit期間中に日経IDでAWS Lambdaを採用っていいうリリースを出されていたりしました。

www.itmedia.co.jp

(追加)Game Tech Session

カプコンにおけるインフラへの取り組み

インフラ面における過去の振り返りからサーバレスへと話が進んでいきます。31ページからスライドの雰囲気が激変します。こういう特徴あるスライド作れるのうらやましい。

f:id:Keisuke69:20170622212122p:plain

資料リンク

DAU 100 万人突破! 急成長を支える Shadowverse のインフラ技術

ログ収集まわりでECSによるコンテナと組み合わせて利用している事例です。

speakerdeck.com

さいごに

というわけでまとめてみましたが、結構な数ですね。コミュニティとかウェブとかではあまり外に出ていない事例もあったかと思います。さらにここでは取り上げなかったセッションでもシステム全体の隅っこに少しだけ動くLambdaファンクションがいたりするようなものも多かったです。

最後に自分の本もまた宣伝しておきますかね。AWS Lambdaを解説した本です。AWS Summitの会場で先行販売して、6月9日から一般販売開始されました。よろしければどうぞmm

 

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

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

 

 

 

買い揃えたキャンプ道具を何となくレビュー③

ブログ分割に伴い、こちらのポストは新しいブログに移されました。

keisuke69.hateblo.jp