iteration 1,2,3

[seven320]

google spread sheet

https://docs.google.com/spreadsheets/d/1FjRUPeDg4W21q1q2YmptCao61iSnMcutcsmBBMvyElk/edit#gid=0

[seven320]

一周の流れ

アプローチ

hakaru サーバをスケールアウトする

想定インパクト

現状 1 台で 100 reqs/sec を捌いているので、2 台になれば 200 reqs/sec になるのではないか。10 倍だぞ 10 倍。

• 想定インパクトの根拠を理論立てて説明する
  • 根拠となる数値やグラフがあれば、説得力が増す
• 優先度付けに使える
• 分からなければ無くてもよいし、大・中・小とかでも良い

モニタリング項目

• 1 秒あたりのリクエスト処理数
• メモリ使用量など懸念があればそこも

結果/考察

10 倍だったぞ！

• 時間内に結果が出ていれば書く
• 想定通りでなかったときは考察をして次に繋げる

[seven320]

アプローチ

DB定義を変数にして，同時接続数を減らす

想定インパクト

全ての502のエラーがtoo many connectionなので現状3%のエラーが消える

結果

[onetk]

アプローチ

DB自体を複数にして負荷分散

想定インパクト

シナリオ2以降でも全ての502のエラーが消える
優先度：中

[onetk]

アプローチ

ローカルのTest環境を作る

想定インパクト

開発・デプロイ速度の増加
優先度：中

[onetk]

アプローチ

デプロイ自動化する

想定インパクト

インスタンスごとにコードのバージョンが分からなくなる事態が起こっているので、デプロイ自動化による、その現象の減少に伴って実験速度の上昇
優先度：中

想定できる具体的なアプローチ

• githubにmaster push→CIでS3にアップ→フックでdeploy
  • メリット:githubにソースを上げれば自動でデプロイされる
  • デメリット:構築に時間がかかりそう
• オートスケールで同じインスタンスを複数立てる
  • メリット:ダメだったらインスタンス殺せばいい
  • デメリット:インスタンスはすぐ立たない
• 複数インスタンスに対して同時にセッションを開きコマンドを同時送信する
  • メリット:楽、一瞬でできる
  • デメリット:自動ではない、現在どの状態に本番環境があるかを確認しなければならない

[onetk]

アプローチ

インスタンスを増やすアプローチの再実験

想定インパクト

全ての502のエラーがtoo many connectionなので現状3%のエラーが消える
昨日の時点で既に行い結果は改善しなかったが、他のチームがインスタンス増加に伴う502の減少を発表していたので、昨日の結果が本当に正しい結果だったのか、確認も含めて再実験

優先度：中

インスタンス１つの現状 in 20191103-1037

[seven320]

day1

アプローチ

ELBに身もづけているインスタンスが１つで処理しきれていなかった説
インスタンス1つで502の数を2、3回確認
インスタンス2つで502の数を2、3回確認
502をなぜ吐いているのかの確認をする
goのリポジトリ周りの最適化

モニタリング項目

ログの分析
インスタンスが1台と2台の時の成功率の比較

結果/考察

インスタンスを2つにすると502が増えた
502はアプリケーション側のToo many connectionsが原因かなという感じだった
EBS系にエラーが吐いていた
DB系周りがネックぽかったので改善していきたい

day1振り返り

良かった点

問題の切り分けがしっかりできている
問題の分析→仮説→検証のような流れがしっかりできていた

反省点

役割分担がルーズだった(個人の能力に頼りっきりだった)
タスクの洗い出しがちょっと甘かったかも
時間の配分がルーズになっていた感じも(iteration周すこと意識)

FB

結果の一覧見れるのよいが、あとでこれは何をしていたのかとなるので、テンプレートの活用も視野に入れて行く方向も
これはA斑のIssueを有効活用している方法をオマージュする

[seven320]

day2

振り返り

他のチームの「オマージュ」もありで
何が効果的かもしっかり見極めて

今日のスケジュール

10:30までにスケジュールを
11:00まで
アプローチ１: DB定義を変数にして，同時接続数を減らす
11:30まで
アプローチ2：

11:30まで itr を2回回せる

担当
log見る / spreadsheet見る 担当
チーズケーキ
cloud watch 担当
でんでん
投げる担当
たか
コーディング
次郎

メモは issueの ここに

本日のアプローチ
🔥DB定義を変数にして，同時接続数を減らす
全502エラーがtoo many connectionなので現状3%のエラーが消える

その後に
🔥インスタンス増やす再実験
🔥DB自体の数を増やす
🔥ローカルのTest環境が欲しい

✅すべて502になった問題
優先度超絶 高い
昨日のdb.close()しているコードのインスタンスが影響しているかも
戻したら治った
🔥デプロイ自動化しないとバージョン分からない問題

[seven320]

day2 午後

アプローチ

　- DBのtoo many connectionの解決
　- ローカル環境の整備

想定インパクト

現状１台でも２台でもエラー率は変わらない．おそらくボトルネックになっているのは
DBへの接続数
DBを変数に格納すれば，エラー率が下がるはず

モニタリング項目

• エラー率（５０２）
• そのたのボトルネックを探す

結果/考察

• エラー率が下がった

* too many errorは下がった

残ったエラーは何に起因しているかは調査中

[seven320]

day2 午後２

アプローチ

too many connections �がまだ残っている．

アプリケーション側でmax_connectionsを制限したい

想定インパクト

• 他チームにおいてすでに実績がある
• too many connectionsを撲滅できる
• 502errorが0.1%いかになる

モニタリング項目

• 1 秒あたりのリクエスト処理数

結果/考察

[seven320]

day2 午後２

アプローチ

too many connections がまだ残っている．
エラー率がばらけるのでインスタンスを増やした際の影響を調べる

想定インパクト

不明

モニタリング項目

1 秒あたりのリクエスト処理数

結果/考察

成功率は上がった

[nt16145]

day2 午後2

アプローチ

cliからインスタンスを増やせるようにする

想定インパクト

インスタンス作成コストの大幅減

結果

コマンド一つで好きなだけhakaruインスタンスを立てれるようになった