「Production Readyサーバーレスウェビナー#01」の参加レポートです！
補欠からの繰り上げで参加できることになりました。
サーバーレスはよくわからんからEC2に既存アーキテクチャを載せ替えただけで結局クラウドの何がいいかわからなかったみたいな人にぴったりのウェビナーだと思いました。
なぜサーバーレスなのか？
- 実装者のリソースを本質にフォーカスするため
- ゲームを作るとき
- サーバーを立てたりログインする仕組みを作らなければいけない
- 必要なことではあるが本質ではない
- ゲームのコアロジックやシナリオにフォーカスしなければならない
- ログインの仕組み→Auth0のようにサーバレスの仕組みを活用してアウトソースすることで開発者のリソースを本質的な部分に費やす
- 品質をアーキテクチャレベルで担保
- 超優秀な人が作ったサーバレスアーキテクチャに乗っかってスケーラビリティ、可用性を担保する
- コストの削減
- アクセスが少ないうちは圧倒的にコストが低い
- 小さく始めて大きくしやすい
個人的超メリット
- インフラの障害は超優秀なクラウドの中の人に任せることでインフラのインシデントコストを削減する
サーバーレスなサービスとは
AWSの用語でいうとフルマネージドサービス
フルマネージドサービスとは
マネージドサービス
機能だけではなく構築や運用管理なども一括して提供してくれるサービス
- RDS
- ElastiCache
とか
フルマネージドサービス
マネージドサービスの提供レベルに加えて、水平方向のスケーリングや冗長化、ディスク容量やパーティショニングの管理も全て含めて提供してくれるサービス
- Lambda
- API Gateway
- S3
- DynamoDB
- SNS
とか
AWS Lambda
- 自動的に水平方向のスケーリングをしてくれる
- コードを動かすためのプラットフォーム管理が不要
- コードが実行された時間に対しての課金
- 1日一回しか実行しない処理とかはメリットを存分に教授できる
- なぜメリットを実現できるのか
- イベント駆動かつステートレスなサービスだから
ステートレスとは
- 永続的なデータを保持しない状態
- 水平方向のスケーリングが可能
スケールの管理はAWSがやってくれる！すごい！
イベント駆動とは
- 何かしらのアクションを元にLambdaが動作すること
- S3にファイルがアップロードされた
- API Gatewayにリクエストがあった
イベントドリブンアーキテクチャ
- Lamdaとサービスがイベントで数珠つなぎとなったマイクロサービスでイベントドリブンなアーキテクチャが自然と出来上がる
- イベンド駆動である制約どおりに実装を行うことで自然とマイクロサービスなアーキテクチャが出来上がる
イベント駆動のメリット
- 耐障害性がある
- ロジックの間にキューを挟むことでロジック障害発生時にキューにリクエストがたまる
- 障害解決後はキューにたまったリクエストが流れ、整合性が保たれる
- ロジックの間にキューを挟むことでロジック障害発生時にキューにリクエストがたまる
- 機能追加に強い
- モノリシックなアーキテクチャだとコードの量が多いほど影響範囲が大きくなる
- イベント駆動だとイベントソースに対して細切れのロジックを追加できるため影響範囲が絞りやすくなる
- モノリシックなアーキテクチャだとコードの量が多いほど影響範囲が大きくなる
まとめ
- ビジネスの本質に集中するためにインフラの運用管理をクラウドに丸投げしよう
- イベントドリブンなアーキテクチャを意識しよう
- フルマネージドサービスファーストで設計しよう
感想
業務レベルでサーバレスサービスを使ってはいましたが、改めて意識する場所、アプローチの方向を確認することができました！
入門レベルの話は自分の中で曖昧になっていた特徴やメリットを再確認するのに最適ですね。
