ISUCON10にインフラ提供として参加しました 提供編

WRITER: whywaita
このエントリーをはてなブックマークに追加

こんにちは。技術本部 プライベートクラウドグループの中西 (@whywaita) です。

2020年9月と10月に行われたISUCON10へ、サイバーエージェント プライベートクラウドグループとしてインフラ提供を行いました。

本記事ではプライベートクラウドのチームが2020年のISUCONにインフラを提供した裏側についてご紹介します。

後編は提供編として、ISUCONのために作られたクラウド基盤であるloviのご紹介と、実際に提供した際に起きた出来事について触れます。
前編である準備編はこちら (isucon.net)にて公開済みですので、そちらも併せてお楽しみください。

自作クラウド基盤 lovi

インフラサイドのチャレンジとして、ISUCON10向けにフルスクラッチなクラウド基盤である “lovi” を開発しました。また、この記事の公開と併せてloviシリーズを全てOSSとして公開しました。

loviのロゴ

https://github.com/lovi-cloud

“lovi”はラテン語で木星を意味する言葉で、各種コンポーネントも木星や宇宙になぞらえた言葉で名付けられています。
例えば、内部コンポーネントには木星の衛星であるエウロパとガニメデが存在していたりします。

コントローラである satelit とエージェントである teleskop を中心に、ISUCONで必要となる機能を一通り実装済みです。

  • インスタンス、ボリュームの作成
  • cloud-init NoCloudを用いたプロビジョニング
  • VMに対する柔軟なCPU Pinningやネットワーク帯域の設定

具体的にどのようなパラメータが設定可能なのかはTerraformプロバイダのQuickStartがありますのでそちらをご覧いただくと分かりやすいかと思います。

その他にもISUCONの物理管理用デーモンであるursaやiSCSIヘルパであるgo-os-brickなどのライブラリは別リポジトリとして切り出して実装済みですので、自分でクラウド基盤を作りたいという方もぜひご活用ください。

また、ご自宅でも利用できるようにストレージアプライアンスに依存していたコードに関してはOSSであるtargetdを利用した実装も用意しました。我が家でも検証用に利用していますが今のところ平和に動作しています。

loviを実装するにあたり、普段運用しているOpenStackはもちろんのこと下記プロダクトも参考にさせていただきました。この場を借りてお礼申し上げます。

また、実装については当初の検証から3月末から予選の9月までを通常の業務を兼務してプライベートクラウドエンジニア2名で取り組んだため約12人月ほどで実装ができました。もし突然クラウド基盤を実装する必要が出た場合はそのぐらいの人月で計算いただければと思います。

なぜフルスクラッチに至ったのか？

弊社は過去に自社開発のクラウド基盤を採用したこともありましたが、現在はほぼ全てのクラウド基盤でOpenStackを採用しています。

そのような状況でOpenStackを利用せずに新しく実装を行ったのは、ISUCONという題材に対する安心感を高めたいという理由でした。OpenStackはnovaやcinderなどのさまざまなコンポーネントによってある程度の互換性や様々な機能を提供することが可能となります。

クラウド基盤としてさまざまな機能を提供する過程で、それなりの計算機リソースが必要となるOpenStackですが、今回のISUCONでは限られたハードウェアの中で展開する都合上フットプリントが小さいクラウド基盤が求められていました。

もちろんISUCONというお祭りですから、チャレンジしてみたいという意欲も大きくありました。普段クラウド基盤を運用している身としてOpenStackの運用面は日々行っているものの、「なぜそのアーキテクチャにしているのか」などコードには見えない部分があるため、自ら再実装することで運用だけでは得がたい学びを得る事ができました。

ISUCON10で利用したアーキテクチャ

ISUCON10では弊チームのプライベートクラウドであるCycloudのアーキテクチャである「ディスクレスハイパーバイザ」を踏襲して実装しました。
Cycloudでは全ての物理筐体上で起動するOSは全てメモリ上に展開し、必要なプロセスはKubernetesのPodとして自動的に展開するアーキテクチャを採用しています。
詳しいところは以前ブログ記事としてまとめていますのでこちらをご参照いただければと思います。

ISUCON環境においてもディスクレスにOSを起動するため、新しくursaを実装しました。
これを用いることで「新しくデータセンターを立ち上げる際にサーバを管理するサーバがない」というデータセンターブートストラップ問題を解決することができました。
今回は物理的なサーバをラックマウントしネットワークを繋いだ上で、作業者のThinkPad上に動作させたursaによってブートストラップを行いました。
その後、SQLiteのデータベースファイルとursaを起動したラックマウントしたサーバ上に移動することにより、データセンターの稼働を開始することができました。

イースターエッグ

今回は自前でクラウド基盤を実装したため、いくつかのイースターエッグを仕込んでいました。短い競技時間の中だけではなかなか見つけづらいところではあったかなと思いますので、こちらでご紹介します。

まず、dmidecode -s system-manufacturer の結果に弊社名を仕込んでいました。

[root@team-xxx ~]# dmidecode -s system-manufacturer
CyberAgent, Inc.

また、皆さまに提供したVMに付与されていたMACアドレスに注目した方はいらっしゃったでしょうか。実は弊社名の略称である”CA”と、弊社の設立記念日でありサイバーの数字表記でもある”0318″を組み合わせてMACアドレスを生成していました。
偶然にもRFC7042にて定義されているLocal MAC Addressの範囲内に入っておりvaildなアドレスを払い出すことができました。第1オクテットがxAのMACアドレスはLocalかつUnicastなアドレスに区分されます。

[root@team-xxx ~]# ip link show ens5
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether ca:03:18:4a:7f:48 brd ff:ff:ff:ff:ff:ff

VM割当スペックについて

最初のミーティングであるキックオフの時点で上記のハードウェアスペックについて作問チームに共有し、その枠内で参加チーム数を決定し実際に競技用VMに割り当てるスペックを決定していきました。

具体的に割り当てられたスペックについては予選開催時と本選開催時ともにGitHubに記載してあるためそちらを参照いただくとして、DiscordやTwitterなどで言及されていたりインフラ側として印象深かったスペック値についてご紹介します。

ディスクサイズについて

予選開催時にはroot用のディスクとして1VMあたり10GB割当していました。この数字は私が決定したのですが、ストレージアプライアンス側には余裕があったもののほぼ手癖で必要最低限のディスク容量を指定していました。

ところが、予選問題中にMySQLのbinlogやクエリログが多く出力されていたチームやElasticSearchに挑戦したチームの中ではディスクフルになるなどの影響があったとDiscordでの感想で何件か頂きました。その節はご迷惑をおかけしました……。

本選ではこれを反省して30GBほど割り当てて運用しました。

IOPSについて

CPUをはじめとして”全チームが性能を使い切っても大丈夫”なようにスペックの設計を行いましたが、唯一その設計を緩和したのがVMごとのIOPSでした。

IOPSに対して何も制限しない状態で1コアのVMを作成したときのfioの結果はRandom R/Wで35,000IOPSほどの性能が発揮できるのですが、他VMの影響を受けないようIOPS制限は必須であると判断しました。

ストレージアプライアンス全体で発揮できるIOPSが約10万IOPSであり、今回の参加チーム上限である500チームを単純に割ると200IOPSとなり、1チーム4VMであることを考えると50IOPSになってしまいました。
libvirtにおいてIOPSのバーストを設定できる total_iops_sec_max_length などの設定も検討したのですが、ベンチマークスコアの安定化などを考慮した上で今回はバーストせずにIOPSの制限をかけることにしました。

最終的にRead / Writeともに1チームあたり予選では200IOPS、本選では800IOPSと設定していました。

ディスクが高速なNVMeを利用しているため1回のI/Oは高速なのですが、libvirtの機能によってIOPSを制限していたため高速に200IOPSを使い切ってしまう状況になり、HDDやNVMeをそのまま利用する状態とは若干違った状況になっていたのではないかと思います。具体的には今回の環境ではI/O負荷の高いプロセスを実行していてもiowaitが100%になることはなく、99%で頭打ちするような状況になっていたことにお気づきの方もいらっしゃったのではないでしょうか。

若干特殊な状況にはなっておりましたが、基本的にはHDDのように書き込みが遅いようなディスクとしてチューニングを行っていただければ十分に良いスコアは出たのではないかと思います。

競技中のインフラメトリクスについて

今回の環境をモニタリングした結果を公開します。
次回以降プライベートクラウドのチームがISUCONにインフラ提供する際にはこのぐらいの規模感で用意すればよい、という指標になれば幸いです。

インターネットトラフィック

まずは予選にて計測されたトラフィックに関するグラフです。

予選のトラフィックは400Mbpsほどでした

“Internet – FW” と書かれているメトリクスが参加者の皆さんに提供したVMを含め、今回のISUCONで用意した環境において発生したインターネット向けの通信です。
正の数がVMからインターネットに向けた通信、負の数がインターネットからVMに向けた通信となっています。

グラフを見ると、開始直後に400Mbpsほどのトラフィックが出ており、その後は徐々にインターネットに向けた通信は減っていく様子が読み取れます。

続いては本選にて計測されたトラフィックのグラフです。

本選のトラフィックは40Mbpsほど、たまにスパイクしていました

本選は予選と比較すると非常にトラフィックが落ち着いていました。
一部多くの通信を行っているところがありますが、よくよく調べてみると管理用マシンで用意していたGitHub Actionsのself-hosted runnerが出していたトラフィックで、本選競技自体は50Mbpsに満たないぐらいのトラフィックで運用されていました。

次に、各VMがインターネットに向けてどのような通信を行ったかについて見てみましょう。

こちらは予選にて計測されたVMからインターネットへの通信を記録したものです。

最初に盛り上がり、徐々に落ちていきます

続いて逆方向、予選にて計測されたインターネットからVMへの通信を記録したものです。

逆方向も同様に、最初に盛り上がり徐々に落ちていきます

詳しく通信を見てみるとGitHubやaptリポジトリなどのIPアドレスに対しての通信が多く発生しており、競技に取り組むためのツールを準備するトラフィックが競技全体を通して最も多かったようです。

ちなみにインターネットからVMに対しての通信が多い、一番トラフィックを流したで賞は予選がチーム「ブラザーズ！」さん、本選がチーム「MN」さんでした、おめでとうございます！

ストレージメトリクス

今回利用していたストレージアプライアンスにおけるメトリクスがこちらです。こちらは4筐体あった中の1筐体のみで観測されたグラフで、概ねこの数字の4倍ほどの性能が出ていました。

ISUCONではストレージに対する負荷はどんどん上がっていきました

IOPSは前述の通りVMにて制限されていたため、約2000IOPSほどで推移していました。
とはいえ競技が進むにつれて定常的にIOPSが上昇しており、参加者の皆さまがうまくチューニングを行い筐体の性能を引き出している様子が見て取れます。

本選の様子も見ていたのですが、問題性質もあってかほぼストレージメトリクスとしては数字が動いていなかったため割愛します。

まとめ

ISUCON10でのインフラ提供の裏側についてお届けしました。

パブリッククラウド以外でのインフラ提供は初期のISUCON以降経験が少なく、お手数をおかけしてしまった点もあったかと思いますが何とか開催できたことを嬉しく思います。

今後も可能な限りコミュニティへの参加と還元を行っていきたいと思います。ぜひ面白そうなお話があればご相談ください。
以前はカンファレンスへのWi-Fi提供なども行っていました。最近は残念ながら物理的なカンファレンスは減ってしまいましたが……。

主催や運営の皆さま、参加者の皆さま、また若輩者の私が言い出した事に対して動いてくださった社内の皆さまに深く感謝申し上げます。

またどこかのイベントでお会いしましょう！

稼働中のサービスで新たに TV デバイスに対応するためにやったこと
次の記事
CA.unity #1 イベントレポート
前の記事