まとめ

[Kase076]

全体的な方針

hakaruのスケールアウトに頼らず、一台の限界に挑戦する！
　* まずはスケールアウトに頼らない
　* スケールアウトだけではコストの問題や限界があるため

やったこと

• DB接続周りの改善 DBのconnectionを一つにする #5
  • db.Open() を一回のみに
  • db.SetMaxOpenConns()で接続数を制限した
• 非同期処理でDBへの書き込みを逃す db.Execを非同期で行う #17
  • goroutine の生成のしすぎでメモリ溢れが起きてしまったので不採択
• バルクインサート 遅延insertしても良いのでは？ #7
  • 定数個(N)おきに同時にinsertする
    • リクエスト数 % N 個のeventLogがDBに書き込まれない
  • 定数時間おきにinsertする
    • 今回のサービスはリアルタイム性が不要だったので妥当な選択であると判断
    • 参考：https://github.com/carlescere/scheduler
• Auto Scaling グループの活用
  • hakaruを最終的に3台に増やした
• 起動テンプレートの活用

結果

• 一台でもシナリオ3を捌けた
  • kakeru 14台
  • 約110万リクエスト
• 今後のことを考えるとより高負荷な状況のことを踏まえ、スケーリングに対応可能なようにした
  • スケーリングしても安定したレスポンスが返ってきた

hakaru 1台 kakeru 14台

hakaru 3台 kakeru 14台

redashからeventLogがすべて格納されていることも確認できた

今後の課題

• バッファリング中のeventLogがメモリ上にしか保持されないため、サーバーが落ちると破棄されてしまう
  • 解決の例：ファイルに出力 → fluentdで送信
• ELBとの通信にKeep-Aliveを設定する
  • ボトルネック部分ではなかったので今回は行わなかった
• デプロイフローを円滑にする
  • 三日間でやるぶんには必要ないと判断
  • 長期的な改善を行うのであれば需要がある
• kakeruのチューニングをする！

進め方でよかった点

• アイデア出してからしっかり行った
• issueやPRを活用して現状や結果の共有ができた
• 役割分担と時間の管理がうまくいった

感想

• 楽しかったです！
• 短い時間内で優先順位をつけ作業するのは大変だった。
• 改善案の根拠を示す難しさと重要性を認識した。
• hakaruの限界を見たかった...
• もっと複雑なサービスの改善もやってみたい。
  • 例：よりリアルタイム性のあるサービスでは？