Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

iteration 1,2,3 #5

Open
seven320 opened this issue Nov 2, 2019 · 12 comments
Open

iteration 1,2,3 #5

seven320 opened this issue Nov 2, 2019 · 12 comments

Comments

@seven320
Copy link
Contributor

seven320 commented Nov 2, 2019 •
edited
Loading

google spread sheet

https://docs.google.com/spreadsheets/d/1FjRUPeDg4W21q1q2YmptCao61iSnMcutcsmBBMvyElk/edit#gid=0
@seven320
Copy link
Contributor Author

seven320 commented Nov 3, 2019

一周の流れ

アプローチ

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

想定インパクト

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

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

モニタリング項目

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

結果/考察

10 倍だったぞ！

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

@seven320
Copy link
Contributor Author

seven320 commented Nov 3, 2019 •
edited by onetk
Loading

アプローチ

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

想定インパクト

全ての502のエラーがtoo many connectionなので現状3%のエラーが消える
スクリーンショット 2019-11-03 10 19 48

結果

image

@onetk
Copy link
Contributor

onetk commented Nov 3, 2019 •
edited
Loading

アプローチ

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

想定インパクト

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

@onetk
Copy link
Contributor

onetk commented Nov 3, 2019 •
edited
Loading

アプローチ

ローカルのTest環境を作る

想定インパクト

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

@onetk
Copy link
Contributor

onetk commented Nov 3, 2019 •
edited by nt16145
Loading

アプローチ

デプロイ自動化する

想定インパクト

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

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

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

@onetk
Copy link
Contributor

onetk commented Nov 3, 2019 •
edited
Loading

アプローチ

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

想定インパクト

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

優先度：中

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

@nt16145 nt16145 closed this as completed Nov 3, 2019
@nt16145 nt16145 reopened this Nov 3, 2019
@seven320
Copy link
Contributor Author

seven320 commented Nov 3, 2019

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
Copy link
Contributor Author

seven320 commented Nov 3, 2019

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
Copy link
Contributor Author

seven320 commented Nov 3, 2019

day2 午後

アプローチ

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

想定インパクト

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

モニタリング項目

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

結果/考察

  • エラー率が下がった

スクリーンショット 2019-11-03 13 47 01

* too many errorは下がった

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

@seven320
Copy link
Contributor Author

seven320 commented Nov 3, 2019 •
edited
Loading

day2 午後２

アプローチ

too many connections �がまだ残っている．
スクリーンショット 2019-11-03 14 27 19
アプリケーション側でmax_connectionsを制限したい

想定インパクト

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

モニタリング項目

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

結果/考察

@seven320
Copy link
Contributor Author

seven320 commented Nov 3, 2019 •
edited
Loading

day2 午後２

アプローチ

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

想定インパクト

不明

モニタリング項目

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

結果/考察

成功率は上がった
スクリーンショット 2019-11-03 15 01 01

@nt16145
Copy link
Contributor

nt16145 commented Nov 3, 2019

day2 午後2

アプローチ

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

想定インパクト

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

結果

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

@seven320 seven320 changed the title report iteration 1,2,3 Nov 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@onetk @nt16145 @seven320