"良い開発者体験"にむけた国内/海外のアーキテクチャLT会 AWS編
iwamasa概要
"良い開発者体験"にむけた国内/海外のアーキテクチャLT会 AWS編
シリコンバレーのスタートアップからメガベンチャーのアーキテクチャに迫る！
| 時間 | セッションタイトル | スピーカー |
|---|---|---|
| 12:00 | オープニング・ご挨拶 | - |
| 12:05 | 『海外アーキテクチャトレンド』 | Amazon Web Services Japan (@_hariby) |
| 12:15 | LT①『複数の外部接続環境で仕様の異なるIncoming Webhookを統一的に扱うためのアーキテクチャ』 | 株式会社LayerX (@shnjtk) |
| 12:25 | LT②『70人の開発者体験を支えるNewsPicksのAWS アーキテクチャ』 | 株式会社ニューズピックス(@integrated1453) |
| 12:35 | LT③『モノレポによるマイクロサービスアーキテクチャの開発運用』 | MODE, Inc.(@banana_umai) |
| 12:45 | LT④『後方互換性を気にしないで開発できる治験プラットフォームのアーキテクチャ』 | サスメド株式会社(@tomomoto_LV3) |
| 12:55 | Q&A | - |
| 13:10 | クロージング | - |
iwamasaハッシュタグは #AWS_findy
iwamasa『海外アーキテクチャトレンド』
スライド
グローバルでどういったアーキテクチャ、デザインパターンが採用されているのか？
スライドで共有していただいた記事
アーキテクチャトレンドを理解するためのキーワード
- 可能性モデル99.999%再考
- セルアーキテクチャ(手前に薄いルーティングを置き、その後ろにCellを配置)
- シャッフルシャーディング
- MTBF/MTTR
- リージョン・AZ単位の分離
- 進化を前提とした(Evolvable)アーキテクチャ
- シンプルに作ってだんだん進化させる(モノリス→マイクロサービスみたいな感じに進化させる)
- 非同期なイベントドリブンのアーキテクチャ
- Serverless Land
- デプロイの安全性
- 変更差分を小さく
- タイム値ラベルデータでのテスト
- ステージごとのデプロイ
- まず自動化を考える
- サーバーレスデザインパターン
- サステナビリティとコスト最適化
- 責任共有モデル
iwamasaQA
国によるSREの違い
組織や国によってまちまち。
AWS/Amazonは「あなたが作ったらあなたが運用しましょう」という考え
それに基づいたチーム構成
カルチャーを含めたチーム作りが大切
AWSの文化は re:Ivent 2022 の Beyond five 9s で触れられているとのこと。
多分こちら
iwamasaLT①『複数の外部接続環境で仕様の異なるIncoming Webhookを統一的に扱うためのアーキテクチャ』
資料
バクラクビジネスカードについて
外部サービス連携がある
サービスによってWebhookの仕様が異なる
- サービスの不具合でWebhookを処理できなかった場合、自社のタイミングでリトライできるようにしたい
- 運用時にどんなメッセージが届くかは事前に全てを把握することは不可能
- メッセージ内容・送信パターンは加盟店次第
- 不具合があっても修正→リリース→手動でリトライしたい
[処理順]
- API Gateway→Lambda
- LambdaでS3に保管→SQSに送信
- 成功したら200
- workerでSQSからジョブを受信→S3から取得
[メリット]
- リトライを任意のタイミングで実行できる
- 不具合があっても修正をリリース後にリトライできる
- 大量に届いても一旦Lambdaでキューイングするため、workerの処理能力に合わせてメッセージ処理できる
まとめ
仕様が異なる複数のWebhookを処理する際は Lambda + S3 + SQS で一度メッセージを保管してworkerで処理することでリトライの仕組みを自社統一できる
Webhookを受けた時点でメッセージが保管されるため、サービスに不具合があっても修正して後からリトライできる
iwamasaLT②『70人の開発者体験を支えるNewsPicksのAWS アーキテクチャ』
資料
EC2インスタンスが100台以上あった
→2年かけてほとんどコンテナ化した
ユーザーに価値を届けることを重視する文化
- 開発者はフルサイクルを自走する
- インフラについてもオーナーシップを持ちたい
EC2運用に対する課題
- インフラに関する認知負荷、作業負荷
- 設定変更のリードタイム
- など
コンテナ化してプロダクト開発/運用のコア業務に集中したい
→AWSのマネージドサービスで管理するように寄せたい
AWS CDK(TypeScript)を採用
- バックエンドがDynamoDBやSQSを使っている
- SDKを普段から触っているから同じような感覚で触れる
- (terraformとの違いが書いていた気がするので後で確認する)
CDKについて
- Constructでインフラ構成を部品化できるため、再利用できる
- 他の環境やサービスに横展開しやすい
- TypeScriptの型を利用してインフラ設定の型を設定できる
- テストが書ける
- 型で変な設定を入れないような制限ができる
ChatOpsでリリースの心理的安全性を向上
- ChatOps + Step Functions
- Slackでボタンをポチるだけにしている(ブログにあるらしい)
ブログは多分こちら
Fargateだと料金が上がるため、EC2にした？(後で資料確認)
コンテナ化・IaC化で先の課題が解決できた
CDKの採用で開発者によるインフラへのコントリビュートが増えた
iwamasaQA
CDKの共通定義はどう管理しているのか？
各サーバーのバックエンドアプリのリポジトリで管理している
サービス横断では現在管理できていない
共通定義の部品化は今後やっていきたいところ
iwamasaLT③『モノレポによるマイクロサービスアーキテクチャの開発運用』
資料
モノレポ
- マイクロサービスのソースコード管理手法の一つ
- 各サービスを一つのリースコードリポジトリで管理する
- 反対派サービス毎にリポジトリを分ける(ポリレポ)
- アメリカのTech系スタートアップだと議論になりがちらしい
メリット
- サービスの一貫性を高くしやすい
- 開発に必要なサービス一式を立ち上げやすい
- 同一言語で実装している場合、共通ライブラリの運用がしやすい
- 複数のサービスやライブラリのコードを同一目的で変更しやすい
- ハード/ソフトな共通化がしやすい(設定、デプロイ、規約など)
デメリット
- CICDパイプラインの構築に工夫が必要
- CICDが遅くなりやすい
- モノレポ自体にベストプラクティスがあるわけではないため、テンプレートが無い
- モノレポに関わる人数や組織の構造によっては難しくなりがち
- コンフリクトの増加やブランチ管理の煩雑化
CICDの工夫
- GitHub Actionsでcontainer imageをビルド→ECRにpush→CodePipelineをトリガー
- GHA WorkflowとCodePipelineはサービス、環境毎に作成
- mainブランチマージ時に影響があればサンドボックスにデプロイ
モノレポ管理の工夫
- 複雑なブランチ運用や長期ブランチを避ける
- モノレポで「あらゆるコード」を管理すべきか？
- NO
- 関連性の少ないコードは分ける
- ex.) ゲートウェイやモバイルアプリは別にしている
まとめ
- 同一言語でバックエンドのマイクロサービスを構築する場合、モノレポは悪くない選択肢
- CICDパイプライン、ブランチ管理などに工夫が必要
iwamasaLT④『後方互換性を気にしないで開発できる治験プラットフォームのアーキテクチャ』
睡眠障害の治療アプリ気になる(切実)
サスメドシステムは臨床試験/治験を実施する機能と治療用アプリをノーコード開発する機能を持っている
→治験コストを下げるようなアプリの開発
→医薬品における臨床試験/治験の効率化
治療アプリ、臨床試験/治験スマホアプリ
- アプリが止まらないようにすることが重要
- 不正利用やデータ漏洩を防ぐことが重要
臨床試験/治験のWebシステム
- 試験実施中にトラブルが発生すると最悪試験中止になる、同時に機能追加・改修を行いたい
構成
- admin site: AWS
- スマホアプリ連携システム: GCP Firebase
アーキテクチャ紹介
バージョンアップによって障害や取得データ傾向が変化すると試験が中止になるリスクがある
必ず一定の期間で終了する
- 一つの試験は一つのversion上で運用される
- versionごとにAPIサーバー、ALB、CloudFront、バッチシステムが含まれている
- version共通で使用する認証やマスタ管理は別である？(メモ取れなかった)
まとめ
- ドメイン特性を理解した上で工夫する
- 既存技術を加味してうまく組み合わせて対応している