VOYAGE GROUPのインターン「Sunrise」に行ってきた話
こんにちはnasaです。
11月の２〜４日で夏のインターンの時もお世話になった某YAGE GROUPに行ってきました！ 今更書きます！
夏に参加したTreasureのほうも参加記録書いたので貼っておきますね
VOYAGE GROUPの夏インターンTreasureに参加した - 心の声を垂れ流す場所
目次
インターン概要
- 期間 11/2~11/4の3日間
- 待遇 ３万円支給
- 交通費支給，滞在場所提供（シェアハウスでした。今回のところは大当たり！)
- 内容 遅いアプリケーションが有るから、負荷に耐えられるようにしてねーという内容。触る範囲はアプリケーションそのものとインフラ構成。
やったこと
４人一組、または３人一組でチームを組み、アプリケーションをどのようなアプローチで高速化するか、インフラ構成をどう変えるか、を話し合いながら爆速にしていきました。
構成はこんな感じ。 hakaruというのが今回使用したアプリケーションです。 ALBがロードバランサー。
(図ではhakaruは2台ありますが、最初は一台しかありません。)
hakaruがやっていることはPOSTリクエストが来たらその内容をDBに書き込むだけ。他には何もやらないシンプルなアプリケーションでした。 (Golangで書かれていて、40行くらい)
高速化と言ってもisuconとは違い、施策を手当り次第に試していくわけではありません。
流れとしては、
- アイディア出し (現状のログやCPU負荷などの様々なメトリクスを見てどのような施策が考えられるか)
- 1ででた施策を実行するとどのような改善が見られるか。見られそうか考える。
- 実装コストも考えつつ、優先順位を決めて、施策を実行していく
- 2で考えた、想定していた改善がされているかを見る。モニタリングする。
- ほかのチームにむけ発表。共有する。
ということをやっていきました。今回はチーム間での競争ではなかったので、他のチームの良いところはドンドン真似していきました。
SLOちゅうのが有るらしい
Service Level Objective
自社のサービスレベル（サービス品質）に関する目標・評価基準を定めたも
らしいです。
最適化は適度にする。 頑張ろうとすると無限にできるが、それって必要なん？となる。
じゃあ、必要なだけって？適度ってどのくらい？という話になる。
SLOという指標がある。
信頼性のあるサービスを提供したいなら、信頼性を定義する。 例えば
- レスポンスタイム
- Request / sec
- 復旧時間 などなど。
何をどのくらい改善したいのかを決めなければ無限に最適が出来てしまう。 最初に目標を決めておくべき。
ということで、今回はリクエストの99%が200で返る。DBにちゃんと書き込まれている。というSLOが設定されていました。
ベンチマーカーについて
SLOは分かったけど、リクエストがどれくらい来るん？という話があるかと思います。
今回のベンチマーカーにはシナリオが３つありました。
- 秒間200リクエスト
- 秒間2,000
- 秒間 20,000
シナリオを１つ返るごとに負荷が10倍になっていきます。
施策を紹介するぜ
DBに１リクエストごとに一回書き込む必要はないだろう、数秒の書き込みの遅延は許されるだろうと思い、リクエストが来たら直接DBに書き込むのではなく、オンメモリで管理しておいて、数秒、または数十秒に一回まとめて書き込むという処理に変更しました。
やるに至った流れとしては、
- 書き込み遅延は許される -> 想定しているアプリケーション的にOK
- DBは顧客のものと言う想定でイジれない。
- 明らかにDBの書き込みで詰まっている。
という背景があり、これは１件１件insertするのではなく、まとめてbulk insertすることで大幅な速度改善がされる!と思い実施しました。
無事、大幅に改善され、シナリオ2(秒間2,000)が捌ければいいなーと思って実行したんですがシナリオ3(秒間20,000)が捌けてしまい、僕らのsunriseは終わりました。
他にも細かいこと色々やったんですが、覚えていません。
まとめ
人の金でインスタンスたてるの楽しい！！
シェアハウスは良いぞー
やはり、シェアハウスは最高に楽しい。
以上。
