「"良い開発者体験"にむけた国内/海外のアーキテクチャLT会 AWS編」参加レポート #AWS_findy

3月９日、「"良い開発者体験"にむけた国内/海外のアーキテクチャLT会 AWS編」に参加しました。

『海外アーキテクチャトレンド』

資料: https://speakerdeck.com/hariby/findy-event-architecture-on-aws
スピーカーはAmazon Web Services Japan @_haribyさん。
AWS Architecture Blog 2022のTop 10の記事を参考に、海外のアーキテクチャトレンドを理解するためのキーワードとして以下の3点を挙げられていました。

• 可用性
• サーバーレス
• サステナビリティ

上記を満たすため、以下のアーキテクチャを取り入れことが重要とのことです。

• 可用性
  • 『Well-Architected Framework 信頼性の柱』
  • Rate and Expected Duration(RED)
    • リージョンAZ単位の分離
    • セルアーキテクチャとシャッフルシャーディング
      • 手前に薄いルーティングレイヤーを置きCellという単位で分割することで影響範囲を狭める
      • DoorDash社が採用している
    • 進化を前提とした（Evolvable）アーキテクチャ
    • 非同期なイベントドリブンなアーキテクチャで疎結合に
• サーバーレス
  • サーバーレスアーキテクチャパターン
  • デプロイの安全性
    • 変更を小さく、自動化も導入
• サステナビリティ
  • 責任共有モデル
  • 『Well-Architected Framework 持続可能性の柱』

LT①『複数の外部接続環境で仕様の異なるIncoming Webhookを統一的に扱うためのアーキテクチャ』

資料: https://speakerdeck.com/shnjtk/layerx-bakuraku-how-to-handle-incoming-webhooks-with-difference-specifications-in-unified-way
スピーカーは株式会社LayerX @shnjtkさん。

自社プロダクト「バクラクビジネスカード」のWebhookのアーキテクチャについて解説されていました。
連携サービスの不具合でWebhookを処理できなかった場合に自社のタイミングでリトライできるようにするため、Lmabda+S3+SQSでworkerを処理しているとのことです。
workerの処理が失敗したらジョブがSQLからDLKに移されるようにして、後に手動でソースキューに戻せばリトライ可能になる仕組みにしているそうです。

LT②『70人の開発者体験を支えるNewsPicksのAWS アーキテクチャ』

資料: https://www.docswell.com/s/integrated1453/ZGXE8P-newspicks-aws-architecture-for-developer-experience
スピーカーは株式会社ニューズピックス(@integrated1453)さん。

エンジニアの開発者体験を重視している
もともとAWSの多数のサーバーを運用していて管理が煩雑だったところを2年かけてコンテナ化して改善したとのこと。
以前はインフラ周りのトラブルがあるとSREに依頼されることがよくあったのが、コンテナ化してプロダクト開発/運用のコア業務に集中できるようになったそうです。
インフラ構成はInfrastructure as Code（CDK TypeScript）で誰でもインフラを触れるようにしたことで、インフラ変更の依頼がSREに集中しないようになったそうです。
また、Slackでリリース作業を実施（ChatOps）してデプロイの心理的安全性を高めているそうです。

LT③『モノレポによるマイクロサービスアーキテクチャの開発運用の実践』

資料: https://speakerdeck.com/bananaumai/monorehoniyorumaikurosahisuakitekutiyanokai-fa-yun-yong
スピーカーはMODE, Inc.@banana_umaiさん。

マイクロサービスアーキテクチャにおいて、モノレポ（マイクロサービスを一つのリポジトリにまとめる）とポリレポ（マイクロサービスを複数のリポジトリに分ける）の是非についてのお話でした。
MODE, Inc.さんではモノレポを採用していて、（ポリレポとの相対的な）メリットとして以下を挙げられていました。

• サービスの一覧性を高くしやすい
• 開発に必要なサービス一式を立ち上げやすい
• 同一言語で実装している場合、共通ライブラリの運用がしやすい
• 複数のサービスやライブラリのコードを同一目的で変更しやすい
• ハード/ソフトな共通化がしやすい（設定、デプロイ、規約など）

反面、デメリットとして以下を挙げられていました。

• CI/CDパイプラインの構築が複雑になる
• モノレポに関わる人数や組織の構造によっては難しくなりがち（コンフリクトの増加やブランチ管理の複雑化など）

デメリットをカバーするために、CI/CDパイプラインをサービス・環境ごとに分けたり、コンフリクトが起こりにくいブランチ運用を工夫しているそうです。

LT④『後方互換性を気にしないで開発できる治験プラットフォームのアーキテクチャ』

スピーカーはサスメド株式会社@tomomoto_LV3さん。

自社プロダクト「サスメドシステム」で採用しているアーキテクチャについて解説されていました。
サスメドシステムは臨床試験/治験を実施する機能と治験用アプリをノーコード開発する機能があり、以下の課題を抱えていたとのことです。

• アプリが止まらないようにすることが重要（アプリが止まっているせいで患者が薬を飲めないという事態があってはいけないので）
• サーバが落ちても動作する、貧弱な回線でも動作する必要がある
• 不正利用やデータ漏洩
• 不正ログイン防止、検知、不正なデータを送信されても正しいデータを取得

エンジニアの努力だけでこれらを実現するのは困難なので、仕組みで防ぎたいと考えて以下のようにしているそうです。

• バージョンごとに独立したシステムが複数ある
  • 1つの治験は1つのバージョンで行われる
  • 認証などは全バージョンで共通の基盤がある
• スマホアプリはFirebaseを採用。オフラインでも動作するように
• ブロックチェーンでデータの改竄を防ぐ

最後に

どのお話でも共通していると感じたのは、少人数でも安定したシステムを提供するためにテクノロジーを駆使している点でした。
「楽するために全力を尽くす」という感じでしょうか。
昔からある格言として「プログラマの三代美徳（「怠惰」「短気」「高慢」）」がありますが、久々にこの言葉を思い出した回でした。