[レポート] Serverless Meetup Japan Virtual #2 の参加メモ #serverlessjp
2020-07-15Serverless Meetup Japan Virtual #2 にオンラインで参加したので、その参加レポート・メモです。
Twitter のハッシュタグは #serverlessjp です。
目次
※登壇資料が追加されれば追記します
タイムテーブル
| Timeline | Title | Speaker |
|---|---|---|
| 20:45-21:00 | Social | ／ |
| 21:00-21:05 | Opening Talk | 吉田真吾 さん |
| 21:05-21:10 | Forkwellさん告知!! | 永田りさ さん |
| 21:10-21:30 | Access to multiple microservices on AWS | 中山桂一 さん |
| 21:30-21:40 | Meetup | Zoom参加メンバーの方々 |
| 21:40-22:00 | Azure Static Web Apps で実現する Serverless CMS | 三宅和之 さん |
| 22:00-22:15 | Meetup | Zoom参加メンバーの方々 |
| 22:15-22:20 | RDS Proxyの話 | 亀田治伸 さん |
| 22:30- | Closing |
セッションレポート
Access to multiple microservices on AWS
- マイクロサービスしてますか？
- 小さく分割された、自立したサービス
- 他のサービスと連携するインターフェース
- デプロイも独立
- データストアも独立
- 障害があったとしても他のサービスに影響を与えない
- フロントエンドから見たマイクロサービスの課題
- たくさんの API を把握する必要がある
- 欲しい情報を得るために複数の API リクエストが必要
- 分散されていることにより
- 非同期になりがち
- 認証・認可が複雑
- モニタリングも複雑
- これらの課題を解決するのが AWS AppSync
- マネージドな GraphQL サービス
- 様々なデータソースを選択可能
- GraphQL
- エンドポイントが一つ
- Query, Mutation, Subscription の 3 つのオペレーションが可能
- 1 回のクエリに複数のリクエスト
- REST API だと欲しい情報それぞれに API リクエストが必要
- 欲しい情報をクライアントが指定
- エンドポイントが一つ
- 選択可能なデータソース
- Lambda
- この時点で実質すべてのデータソースに対応可能
- DynamoDB
- トランザクションにも対応
- Elasticserch Service
- Aurora Serverless
- HTTP Endpoint
- SigV4 対応
- Lambda
- フロントエンドからは AppSync のみにリクエスト
- AppSync の裏に API Gateway を置く
- Cognito 認証
- IAM 認証
- Pipeline Resolver 認証
- JWT トークンを使用した認証などを取り入れたい場合
- API Gateway の Lambda オーソライザーと似たような形
- AppSync の裏に API Gateway を置く
- GraphQL リゾルバのデバッグ
- CloudWatch Logs Insight
- Subscription
- 決済サービスにリクエスト
- 結果は非同期で API にコールバックされる
- データストアのデータを更新したら AppSync に Mutation する必要がある
- X-Ray を使ったモニタリング
- まとめ
- フロントエンドをシンプルにしやすい
- 細やかな認証を扱いやすい
- CloudWatch Logs Insight や X-Ray をあわせて使うと捗る
Q&A
- Q. フロントエンドからの処理はシンプルになるが、その後ろのレイテンシなどが気になる
- A. キャッシュを有効可する (裏では ElastiCache を使っている)
- Q. マイクロサービスをたくさん使うとインターフェースの齟齬が出てくるが、AppSync を入れた場合に E2E テストはどうするか。
- A. 具体的な知見はない。が、普通の E2E テストで対応。マッピングの管理は辛い。
- Q. REST API から AppSync に移ったときに、スキーマの型が少ないのが辛くないか？
- A. 力技で頑張る。Swagger は階層も一つのオブジェクトとして使えるが、 GraphQL のスキーマ定義だと辛い。
- Q. BFF だけ切り出すというアカウント戦略について
- A. すべてのサービスが一つのアカウントに入っている状態。ただし、サービスが増えてくるのであればアカウントは分けたほうがよいと考えている。
Azure Static Web Apps で実現する Serverless CMS
- Microsoft MVP (for Microsoft Azure)
- Azure Static Web Apps (preview)
- 静的サイトのホスティング
- GitHub Actions と統合された CI/CD
- Azure Functions によるサーバレス API の統合
- やっと出てきてくれたという感じ
- Netlify みたいな感じ
- Azure Static Web Apps – App service | Microsoft Azure
- デプロイの仕組み
- GitHub Actions に統合されている
- 特に特別な設定は必要ない
- ホスティングサービスというよりも、 CI/CD に工夫が詰まっている
- 統合された API
- リポジトリに BFF (APIs) を共存させると GitHub Actions が良しなにデプロイしてくれる
- Azure Function (Node.js) で実装
- ユースケース
- SPA
- SSG : Static Site Generator (JAM Stack 含む)
- Static Site Generator
- 動的コンテンツを事前にレンダリング
- Jekyll, Gatsby, HUGO, Next.js, Nuxt.js など
- Git ベースの SSG
- コンテンツは Git リポジトリで管理
- Markdown からコンテンツを作成・更新
- DB, CMS が不要
- nuxt/content による SSG
- Nuxt.js の Git-based Headless CMS モジュール
- Markdown 内で Vue コンポーネントを利用可能
- PR でステージ環境が作成される
- API-basses SSG (JAM Stack)
- コンテンツは Headless CSM で管理
- 管理画面だけ提供されている
- ビルドプロセスで CMS の API からコンテンツを取得
- 一般ユーザがコンテンツを更新するのに向いている
-
API-first content platform to build digital experiences | Contentful
- WYSIWYG で編集可能
- WordPress から移行してくる人が多い
- microsoft/static-web-apps-gallery-code-samples: A gallery of awesome projects deployed on Azure Static Web Apps 🎉
- GitHub Actions に癖がある
- ビルドとデプロイが分割できない
- 凝ったことをしようとすると辛い
- E2E テスト
- Lint
Q&A
- Q. Static Web Apps の API の機能で一番欲しい機能は?
- A. Azure Functions にはいろんな機能があるが、 コールドスタートが可能なプランがあればいい。というか、無いと辛い。フロントエンドでコールドスタートは辛い。
- Q. 今は GitHub Actions のみだが、 GitLab などにも対応するか?
- A. issue には上がっている。対応はプッシュしているが、時間はかかるかもしれない。
- Q. デプロイ先は Azure ストレージ?
- A. Azure ストレージではない。特別な場所が用意されている。もろもろ隠蔽されている。Firebase も隠蔽されている。Amplify は S3 とか諸々作成される。
- Q. SSL は?
- A. 無償。カスタムドメインに対しても。(今だけかも)
RDS Proxyの話
- 当初から抱えていた Lambda の問題
- Lambda から VPC への通信
- 今は EC2 も RDS も VPC 内に作成する必要がある
- Lambda は VPC の外
- VPC の中に入るには ENI を経由する必要がある
- パフォーマンスの問題
- 2019 年 9 月にパフォーマンス改善
- VPC の中に入るには ENI を経由する必要がある
- RDB へのコネクション爆発
- Lambda は水平スケーリング
- コネクションを張るのは重い (セッションハンドリングなど)
- Lambda でコネクションプーリングをはると RDS が待ちっぱなしになる
- Lambda から VPC への通信
- RDS Proxy
- VPC 内に作成される
- Aurora, MySQL, PostgreSQL に対応
- Aurora Serverless には非対応
- 本当にフロントエンドに使えるかどうかは検証次第
- メリット
- コネクションの開閉回数を減らす -> DB リソースの適切な管理
- RDS フェイルオーバー時間の短縮 (最大 66%)
- DNS 伝達の遅延解消
- Secret Manager , IAM との連携で認証の管理
- 高負荷時にはスロットリング
Q&A
- Q. 導入は進んでいる?
- A. 認知はされ始めていると思うが、プロダクションへの導入はまだ。挙動、癖、パフォーマンスについては検証・判断が必要。
- Q. ユーザからの期待度は?
- A. 導入には POC を経てから。使っていただいてフィードバックをもらったほうが改善が進む。
- Q. Lambda 以外からのユースケースは?
- A. 水平スケーリングするサービス (コンテナなど) でコネクションプールが枯渇するようなことがあるなら使う余地がある。あくまでも RDS 側のサービスなので、 RDS の気持ちになってプーリングサイズを決めることができる。
まとめ
Serverless Meetup Japan Virtual #2 の参加メモでした。
AppSync については、 Amplify ハンズオンで少し触った程度なので、今後 GraphQL も含めて勉強していきたいなと思っているところです。
Azure Static Web Apps については、 Azure (というか Microsoft) ならではの GitHub (Actions) との連携がとても工夫されているなという印象でした。さまざまな静的サイトのホスティング、精製方法について知ることができました。
RDS Proxy については、 過去のアンチパターンを解消することができるものとして、サーバレスの環境を大きく変えるものだなという印象です。先日開催された下記のイベントでは濃い話を聞くことができました。
普段 AWS の話を聞くことが多いので、 Azure の話を聞くことができたの非常に面白かったです。
オンライン開催、登壇されたみなさまおつかれさまでした! ありがとうございました。
comments powered by Disqus