全体流れ

[ramenjuniti]

シナリオ1

動かした結果

Too Many connectionsがでる

アプローチ

• デフォルトでは無制限にコネクションを持とうとするので、SetMaxOpenConnsでDBとのコネクション上限をつける 接続上限をつける #12
• リクエストのたびにPoolを作るようなコードになっていたので、Poolを作るコードをhandlerの外に切り出した Poolが複数あるのではないか？ #15

結果

Too Many connectionsが無くなり、インスタンス1つでシナリオ1をクリア

[ramenjuniti]

シナリオ2

アプローチ

• アクセス数が増えたことによってToo many open filesが出てしまう、対策としてulimitの上限を1006500まで上げて対策をした シナリオ２でToo many open filesが出る #17
• 同時アクセス数がtcpソケットの上限を超えてしまいkernel: TCP: too many orphaned socketsが出てしまう、対策としてhakaruを6つに増やして対策をした 消えたリクエストの問題がDB周りの処理の遅さが原因かの確認 #20 (comment)
• db.Prepareのやり過ぎが原因でCan't create more than max_prepared_stmt_count statements (current value: 16382)がでてしまう、対策としてdb.Prepareを外部に切り出すことで対策をした 消えたリクエストの問題がDB周りの処理の遅さが原因かの確認 #20 (comment)
• DB周りの処理が遅く504が帰ってきてしまう、対策としてSetMaxIdleConnsを10に変更 消えたリクエストの問題がDB周りの処理の遅さが原因かの確認 #20 (comment)

結果/考察

結果インスタンス6つでシナリオ２をクリア

[ramenjuniti]

シナリオ3

動かした結果

80万は捌けた。でも504出てる。

時間かかってる。

ELBのメトリクス

アプリケーションが遅く、504がでた。この構成の限界。

DB処理を無くした結果

DB処理を無くしたところ、全部通った。
DB処理が遅かったことがわかった。

インスタンスめっちゃ増やしてやってみる

6 -> 12に増やす

504出た。やはりDB周りの処理を改善しないといけない。

[ramenjuniti]

今後の課題と解決方法

アプリケーション

• DB処理を切り出す（bulk insertなど)

構成

• kenesisやfluentdを導入する

構成図↓

[YamagishiRyu]

進め方でうまくいったもの

• 最小のリソースを意識できた(余計なコードを書かない)
• 一つ一つ理由を見つけて確実に最大インパクトのものを選択できた(必然的にすることがわかった)
• ログが共有できてて原因を考えやすかった
• 他のチームのいいところを吸収することができた(他のチームのチャンネルにちゃんと入った)
• たびたびのぺいさんの授業がとても役に立った
• 役割分担が完璧だった(サイクル回すのが良い)
• 🎉くぎが今日誕生日 🎉

[yamato3310]

感想

• タピオカの作り方、作るときはビビらないですべてを使い切る
• 普段見ないToo Many hogehoge をたくさんみることができた
• ボトルネックとなる部分の切り分け方を知ることができた
• わりとちょっとした改善で対処できることがわかった
• AWS力が上がった
• お金、大事