まえがき

ぷりちゃんわ!初めましてMarcoです。本当に初めましてか?
最近、起きている時間の半分近くが某eSportsタイトルの観戦に充てられているような気がして、ちょっとまずいんじゃないかと現実を見始めています。
現実を見ようとすると、大学図書館で借りてきたたくさんの小説がこちらを見てきます。これは仕方がないので覗き込みますよね。

さて今回の記事は、先日参加したISUCON8についてです。
チームはソフトウェア工房の有志三人チーム出場しました。どこかのキラッとしている作品みたいなチーム名でしたが、記事を読み進めていただければわかる人にはわかると思います。
先に予選の結果を述べておくと、ほぼ初期得点から変動させることは出来ませんでした。
この記事では私の担当したウェブサーバーについて言及します。実はデータベースも担当でしたが、事前に用意しておいたコンフィグを流し込む程度しか触れていないので言及しません。
それでは、反省と振り返りのはじまりはじまりー。

第零章:h2oという未確認ウェブサーバー

コミッターの方々、申し訳ありません。私はh2oというウェブサーバー自体知りませんでした。
開始直後にnginxのサービスがない!( sudo systemctl status nginx.serviceそんなのねえ!!って言ってきました)と気がつき、ブラウザのDeveloper ToolsからResponse Headersを確認し、このとき未知との遭遇を果たしたのです。
すぐさまググり、早いのは確かなのかとわかりましたが、事前の方針で「基本的に、対策したことや経験のあることしかやらない」と決めていたので、nginxに載せ替えることは即決定しました。
この判断はとても早く、出来る限りのことを尽くすという点でよかったと思います。
――まあ、よかったのはここまでのことなんですけどね。えもえも~~(白目)

第一章:自力ロードバランス

さらなるまさか。当日マニュアルを読んで驚きました。ポータルサイトのサーバー選択画面を見て気が遠くなりました。
ベンチマーカー側で自動的にロードバランスしてくれるなんて、優しいことはありませんでした。
昨年の問題も解き、それ以前の記事も読んでいましたが、あまりロードバランスを気にしている方は多く居なかったような気がしていました。
ウェブサーバーのチューニングは、基本的にはキャッシュ周りが大きなウェイトを占め、レスポンスヘッダに全体の知識があると更に強みが得られるというものを予想していたため、この展開は正直苦しかったです。
事前の方針であった「対策したことや経験のあることしかやらない」というのは早々に放棄することになりました。(やってみなくちゃわからない!

第二章:proxy_set_header

とりあえずはnginxに載せ替えが済み、試しに動かしてみるかーと動かしました。――が、cssやjsなどの静的コンテンツが正しく読み込まれずfailしてしまします。
当日メモをあまり残していなかったので記憶が曖昧(+Configの内容も曖昧)ですが、ロードバランスするように書いてから、一旦二台目に分散させないようにコメントアウトして試したときのことでした。(http://127.0.0.1/cssなどを取りに行くよう展開されてしまった)
Goのコードを軽く読んでみると、index.tmplで定義され、c.Renderで動的に展開されていることがわかり、headerのhostを読んできているようです。
事前の分析でわかっていたことではありますが、ここにきてヘッダーの(操作を含めた)知識が問われます。ポンコツなのでその場で調べました。
調べたところ、nginxにおいてproxy_set_headerでリバースプロキシ時のヘッダを操作できるとわかりました。
結果、proxy_set_header Host $host;と追記することで意図しない展開を防ぐことが出来ました。
正直書いたら動いたという認識が強いので、もう少し理解を強める必要はあるかなと考えています。

第三章:悲しみの予選終了

こんなの全然エモくない!んですが、悲しいことにこの程度のことを終えたあたりで時間がやってきたような気がします。
おそらく最大のボトルネックはgetEventsやらgetEventだと思っていますが、それにしても自分が任された仕事を全うできたとは言えないでしょう。
加えて、DBのチューニングに触れられていなかったことも問題ですし、時間がさければ少しでもスコアの改善につながったかもしれません。
ある程度実力を考慮してスケーリングする改善(最初は載せ替え、次にロードバランスに取り掛かる……)を実践できたとはいえ、流石にまずいところが多かったなというのが正直なところでした。
全体を通して悔しいところが多かったんですが、特にロードバランスが適切に行えなかったのが滅茶苦茶悔しかったので、先日追試を行い、ロードバランスする際の適切なコンフィグを学びました。

第四章:雪辱のロードバランステスト

二台のサーバーをConoHaで、OSは本番とは異なりますがUbuntu、Webサーバはもちろんnginxでテストを行いました。
一台目をロードバランサ兼Webサーバ、二台目はWebサーバとしました。
両方ともローカルネットワークに所属させ、以下のようになっています。

具体的にコンフィグは以下です。テスト用なので推奨されないところがあり、特にCache-Controlは違いがわかるようにするためです。(serverディレクティブ等一部抜粋)

一台目

二台目

こうすることで、一台目の:80にアクセスすると一台目の:7650と二台目の:80に振り分けることが出来ます。
それぞれのサーバに異なるhtmlファイルを用意し、実際に試してみます。

既にサーバを削除しているのでアドレスの欄を一部消していますが、これらのスクリーンショットは同じIPにアクセスしています。
同じIPにアクセスしていても、異なるhtmlが返ってきているとわかります。
本番でもこれが書けたら良かったんですけど、焦っていたんですかね……。まあそういうこともあります。多分。

エピローグ:戦いを終えて

なーんもできませんでした。もっと経験がないと太刀打ち出来ないとは思うんですが、バックエンドに触れてみるきっかけになりそうです。
最近、どの分野にどうやって関わっていくのがいいのか未だに迷っているので、そのあたりも考えていかなければなと危機感を感じています。
今後はGoのコーディングや保守性の高いウェブサービス、講義に力を入れて取り組んでいきたいなと思っています。
最後になりますが、ISUCONの運営、様々な支援を行ってくださった方々、企業様、本当にありがとうございました。とても楽しかったです。
他のメンバーもブログを公開すると思いますが、三名ともソフトウェア工房で活動しているメンバーです。興味のある方はぜひお越しください!
以上、ISUCON8予選のレポートでした。長々とすみませんでした><。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)