「アーキテクチャConference2024」に参加してきました

勉強会メモ

NewSQLを用いたDB分離のマルチテナントアーキテクチャー〜ecforce編〜

  • PingCAP株式会社 日下 太智さん
  • 株式会社SUPER STUDIO 田幸 久志さん

マルチテナントでのDB分離

  • ECサービスを提供している
  • 1400以上の店舗を350以上のDBで管理
  • RDS for MySQLとAuroraを使ってる
  • アーキテクチャ戦略
    • マルチインスタンス
    • シングルインスタンスマルチDB
      • DB別に分ける
    • シングルインスタンスシングルDB
      • レコード別に分ける
    • 今は上2つを併用
      • 特定shopでは有効なindexが別shopでは非効率とか
      • shopによってDBの使い方が違うこともある
      • 歴史的背景でrow level securityがない
  • 課題感
    • リソースの増大
      • DBインスタンス300+
      • どのshopに影響あるかなどの調査大変
      • 特定shopを増強したい時にどこを強化すればいいか判断大変
      • メンテで止めるときの影響調査大変
    • コスト
      • 多すぎるのでコストもかかる
    • 性能面
      • 新機能の検討でDBがネックで断念することも
  • 対処の検討
    • OSSのTiDBを知った
    • k8s上で検証したら良さそうだけど運用はつらそう
      • OSSなのでサポートがほしい
  • TiDB Cloud
  • TiDB
    • MySQL互換(100%ではないが)
    • 分散型SQLデータベース
      • アプリから見ると1つのDBのように見える
      • Writeのスケールもできる
      • バージョンアップやDDLもオンラインで
      • ネットワークを解するのでオーバーヘッドはある
    • 実態は分散kvs
    • ACIDトランザクション
    • プライマリーキーのレンジで自動シャーディング
  • 移行作業
    • AutoIncrementのデフォルトの挙動が違った
      • 順序性があることに意味のある実装にしてしまっていたので個別に設定をした
    • 機能面ではMySQLと遜色なし

大規模トラフィックを支えるゲームバックエンドの課題と構成の変遷 〜安定したゲーム体験を実現するために〜

ゲームのアーキテクチャ

  • クライアントはunityでバックエンドはAPIサーバ
    • 普通のwebとにてる
  • リアルタイムに情報を連携するためのサーバもある
    • ユーザ同士で連携するようなゲームでは操作や状態の変化をリアルタイムで共有する
    • WebSocketで常時接続
  • 10年前のアーキテクチャ
    • AWSで
    • APIサーバ/リアルタイムサーバはEC2で
    • EC2上にMySQL
    • 度々サーバ障害でサービスが止まっていた
      • ローンチ時やイベント時に急激にアクセスが増加する
    • データ量増加でDB負荷増加も
      • 時間がない中での対応
      • 同じスキーマのDBインスタンスを複製することで対応
      • 余計なデータまで複製されてる
      • 皇族ではシャーディングもしたけど運用負荷が高い
  • 5年前のアーキテクチャ
    • GoogleCloudに移行
    • GKE上で動作
    • CloudSpannerとMySQL
      • 用途に応じて使い分け
    • CloudSpanner
      • ボタン一つでスケールイン/アウト
      • 実装でシャーディングを意識する必要ない
      • ゼロダウンタイム
    • k8s/GKEへの移行によって運用コストが大幅減
  • その後
    • GKE + Spannerは大成功
    • 対戦型のゲームが多く控える
    • リアルタイムサーバの強化
      • デプロイが大変
        • 常時接続されてる
        • 更新起因で切断されてはいけない
      • サーバ管理が主導
        • あんまりさわらないようにという存在に
      • 属人化もしていた
      • 組織的なアーキテクチャ変更
        • リアルタイムサーバを支えるチームが誕生
  • 最新のアーキテクチャ
    • agones
      • リアルタイムサーバの管理に使う
      • Googleのゲームソリューション
      • k8sが動くところなら動く
      • リアルタイムサーバの割当などをやってくれる
    • open match
      • マッチングメイキングサービス
      • マッチング周りは非常に複雑
      • 開発者がロジックの実装に集中できるようになる

出前館のマルチプロダクト戦略を支えるアーキテクチャ ～技術的負債を解消しながら事業を多角化する～

マルチプロダクト開発

  • 出前館の事業
    • フードだけでなくノンフードにも広がっている
    • さらに配達機能の新たな価値提供
  • クイックマート
    • ヤフーショッピングで注文して出前館の仕組みで配達
    • 注文のコンシューマが違うだけで既存をそのまま使えるのでは？
      • →そうはいかなかった
    • フードとノンフードのドメイン特性が大きく違う
      • 在庫管理/ピッキング/医薬品などフードではなかったことがたくさん
    • orderとmerchantはフードとノンフード別で作った
  • 技術的アプローチ
    • マイクロサービス
      • ドメインやアクターが多様で複雑だった
      • 出前館の既存システムでマイクロサービス化を進めていた
    • イベント駆動
      • 例えば注文のキャンセルなどいくつものサービスに連携しないといけない
      • リクエスト側が主体でハンドリングすると複雑になって負担が大きい
      • queueにイベントを流して各サービスが今シュームする

ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史をADRから振り返る

アーキテクチャ変遷

  • ADR
    • アーキテクチャの意思決定の記録を示す
    • zozoでは2021から導入
      • 議事録文化はあったが追うのも大変だった
      • トップダウンではなく現場レベルから
    • なぜ書くか
      • 意思決定の背景を理解するため
      • 当時は適切だったが今は違うとか
      • 当時の判断が間違っていたとか
  • zozoのアーキテクチャ
    • 2004年サービス開始
    • 2017年までは旧アーキテクチャ
      • オンプレ
      • Windowsサーバ
      • VBScript
        • 更新がされなくなった
      • SQL Server
      • ストアドプロシジャにロジックが
        • 当時はネットワークが遅いからデータに近いところで演算するのは速かった
        • スケールしづらい
        • テスト書きづらい
    • 2017年からリプレイス開始
    • 2020年からリプレイス再計画
      • 2019年に完了予定がまだph1進行中だった
      • 柔軟なシステム
      • 開発生産性
        • マイクロサービス化
        • 並行開発できるように
        • リリースの順番待ち解消
      • 技術のモダン化
  • 事業を止めない移行
    • リプレイスに専念ではなく機能開発を続けながら開発
    • 停止時間は設けず売上損失を発生させずに移行
  • 技術スタック
    • Java/SpringBoot
      • 息が長くサイドリプレイスを行うリスクが小さいこと
      • 市場での採用実績が豊富で業務委託含めて確保しやすいこと
    • go
      • 補完的なゲントとして採用
      • FaaSのような場面で活用
    • python
    • AWS
      • 元はAzureだった
      • 人材採用や廃れるリスク
    • Google Cloud
      • BigQueryなど
      • TPUを活用した機械学習モデルの高速トレーニング
      • MLOpsに対応したエコシステム
    • Next.React
      • VBScriptがHTMLを返してjQueryで動的処理をしていた
      • ページごとにCSR/SSR/SSGを切り替えている

140年の歴史あるエンタープライズ企業の内製化×マイクロサービス化への航海

内製開発チームとマイクロサービス化

  • 2022年に内製チーム発足
    • 自社プロダクトを開発するチーム
    • 最初はフロントエンドとBFFのみ
    • myTOKYOGAS
      • ガスや電気の使用量を確認できるサービス
      • Next/React/GrahpQL/NestJSでリプレイス
    • エネルギー小売全面自由化
      • ガスの顧客離れ
      • 電気のシェアは拡大
      • デジタルでの接点の重要性の増加
      • アジャイルに継続的な改善
  • マイクロサービス
    • BFFとバックエンドの間に境界線
      • 内製チーム管理と既存バックエンド
      • 既存バックエンドはリフト&シフトでクラウドには乗せた
    • レガシーなバックエンドを吸収するためにBFFを膨らます
      • BFFの不具合があるといろんなFEに波及してしまう
    • バックエンドをマイクロサービス化してBFFを正常な形へ
    • 理想論はある中でチームや組織のの状況を見て判断
  • 技術選定
    • Terraform/GitHubActions
    • k8s/Istio/Karpenter
    • TiDB
    • Datadog
  • なぜk8s
  • なぜTiDB
    • 最後まで悩んだところ
    • 年間1000万レコードの増加
    • 履歴も保持するのですぐに億超えする
    • 負荷
      • ピーク時は263rpsが5分
      • 通常時は36rpsが5分
      • 瞬間最大は526rpsが10分

複雑なCI/CDから脱却したアーキテクチャ：NTTグループの内製プラットフォーム事例を通して

CI/CDの改善

  • デプロイ容易性をどう高めるか
  • アプリ開発者とインフラ担当者の境界
    • アプリ開発者は作るところまで
    • インフラ担当者が検証環境で試験したりデプロイしたりする
  • デプロイ自動化
    • Ansibleで自動化していたが毎回違うplaybookを書いていた
    • スクリプトが増えて組み合わせも増えていた
      • 属人化
  • デプロイのバリエーションを減らす -
    • お互いのドメインに踏み込んで議論
    • ゴール思考で小さく進める
      • 議論検証を繰り返し最適を探す
    • コンテナ/k8sへ
    • ブルーグリーンデプロイメント
      • 現行と新バージョン両方稼働して切り替える
      • 合わない仕組みや機能は修正
  • デプロイの主役をアプリ開発者に
    • 一貫性のあるデプロイを強制する
      • 検証環境で試験が通らないと本番にデプロイできないようにする
      • パイプラインで制御/共通化
    • 開発者でも操作できるように
      • ボタン1つでデプロイできるように
      • トラブル時はダッシュボードでログが確認できる