ありがたいことに、3年前に#ssmjp 2017/06で話したスライド
をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。
サーバーレスアーキテクチャ #とは
当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。
書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。
サーバーレス三種の神器
今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。
ちなみにAzureを含めておさらいすると、こんな感じの対応になります。
勝手にスケールするデータストア
- Amazon DynamoDB、Amazon DocumentDB ↔ Cosmos DB
- Amazon S3 ↔ Blob Storage、Data Lake Storage Gen2
- Amazon Aurora Serverless ↔ SQL Database serverless
勝手にスケールするソフトウェア実行環境
- AWS Lambda ↔ Azure Functions
- (AWS Fargate ↔ Azure Container Instances)
それらをつなげる枠組み
- Amazon Kinesis Streams ↔ EventHubs
- Amazon Simple Queue Service (SQS) ↔ Queue Storage、Service Bus
- Amazon Simple Notification Service (SNS) ↔ EventGrid
- AWS Step Functions ↔ Logic Apps、Durable Functions
- Amazon API Gateway ↔ (Functions組み込み機能)、API Management
この辺は今もあまり変わらずです。
この構成の肝は、クラウドサービスの構成と、関数のデプロイを完全に分けていることです。AWS SAMやServerless Frameworkで普通にやると、関数本体がCloudFormationスタックに入ってしまい、リアルからデータが上がってくる「本番環境」で高速に試行錯誤を繰り返すIoTビジネスの特性とちょっと合わないと感じたので、ここを切り離しました。ただApexがメンテされなくなってしまったので、今ならlambrollですね。
Azureでも同じように、全体の構成をTerraformで行い、関数は別レポジトリからデプロイしています。
サーバーレスあるある選手権 Lambda編
ログそのものは現状でも余り変わっていないのですが、追いかける部分に関してはAWS X-Rayの登場でだいぶ改善されました。AWSサービスへの外部リクエストは何もしなくても記録されますし、外部サービスや重い内部処理をプロファイリングしたければサブセグメントを生成してあげればX-Rayの時系列トレースグラフに表示できます。
Azureの場合はVSCode拡張からリアルタイムでログを見ることができます。Application InsightsからX-Rayと同じようにサービス間のコールグラフやサブセグメントごとのトレースグラフが見られるのも同じです。
ここは今でも変わっていませんが、その後運用して判った部分としてはmemory_sizeの調整になった時点で消費メモリ量が問題になることはあまりない（ざっと見て最大消費量より多ければ良い）ので、余程メモリ変動の大きい処理をしていないのであれば、カスタムメトリクスだして追いかけるほどではないです。逆に言えば、メモリ変動が大きい処理があるのであれば、どこかで仕組みを変えて処理量のほうを平準化できないか考えた方が良いです。
このスライドの中で状況がもっとも変わった部分です。なんとかしてくれました。
そもそもVPC環境でのLambda起動の仕組みが大幅に改善されました。
ENIを生やしたインスタンスを個別に作成していたものが、基盤側で用意した共有ENIにNATされるようになったので、15秒ほどかかっていたのが1秒前後になりコールドスタートが実用的な範囲になりました。
また、RDSへの同時接続数も、Lambda側で同時実行数が設定できるようになり、RDS側にもフルマネージドのコネクションプーリングRDS Proxyが提供されたので、問題にならなくなりました。
そもそもVPCを使わずAurora ServerlessのData APIを使うという選択肢もできました。
とはいえ、依然としてRedisなどはVPCの中にしか作成できないので、VPCを廃絶できないのがおしいところではあります。
サーバーレスあるある選手権 Kinesis編
ここも大幅に改善されたポイントです。
待ち時間を指定できるようになったので、データが少ない場合の処理効率が良くなりました。
またKinesis Data Streams側のシャード数と掛け算でLambda側の「Parallelization Factor」で並列実行できるようになったため、時間が掛かる処理をぶら下げたときにシャード数まで引き上げずに済むようになったのも地味に大きなポイントです。これまではKinesis側のリミット(1MB/sまたは1,000レコード/秒)より大幅に少ないデータしかないにもかかわらず、シャード一本月1500円(14.04USD)が掛かっていました。
きました。使っています。
東京には来てくれたのですが、結局うまく処理にはまらずに現状使っていません。
どちらかというと、Apache Flinkで分析処理を実装できるようになった方が個人的にインパクトが大きいです。
イベントソーシングパターンなど、ストリーミングデータに対してステートを持った継続処理を実装するユースケースがふえているのでもっと活用事例が増えて欲しいところです。
サーバーレスあるある選手権 DynamoDB編
KVSベースでの設計がRDBに比べて違うノウハウが必要となるのは以前通りです。これはもうキーベースで分散するデータストアである以上は逃げられません。とはいえ、サーバーレス開発の普及によって世の中の情報もだいぶ増えてきたので、3年前よりは実感的にはだいぶ始めやすくなったのではないでしょうか。
DynamoDBのコスト問題はまだまだ苦労する部分ですが、オンデマンドキャパシティーモードが用意されたので、リクエスト数が急激にスパイクするようなケースでも安心して使えるようになったのは大きいです。
ただ、オンデマンドキャパシティーモードの方が「単価」が大幅に高いため、常時リクエストがあるようなケースではかえって高くなってしまうこともあり、そこはユースケースと運用コストや障害リスクに見合った選択が必要です。
バックアップは完璧に用意されました。オンデマンドもPITRもあります。
注意としては、あくまでバックアップはDynamoDBサービス内にリストア可能な形で保存されるだけです。データ自体をCSVやJSONなどでエクスポートしたい場合は、これまで通りDataPipelineをつかったり、ひたすらスキャンでページを手繰る必要があります。
まだまだ道半ば
結局DynamoDBだけでは厳しくなったので、現在ではRedisも併用しています。
このあたりは、先日のServerless Meetup Tokyo #16でも話しました。
現在は、お客様や大人の事情に合わせて、上でも書いたとおりAzureとAWSで両刀でやっています。GCPでもだいたいできそうな感触はありますが、案件ください。
3年前と比べると、大きな障壁はかなり取り除かれ、頑張ればだいたい問題ない、とはっきり言えるところまで来ました。
昨今、ソフトウェア開発の手法で社会や組織を変革し続けるデジタルトランスフォーメーションの波が来ていますが、特にIoTではとにかくサービスデリバリの高速化が重要です。サーバーレスアーキテクチャという選択肢で正解だったというのがこの3年間の最終的な評価です。
宣伝
