こんにちは。株式会社サイバーエージェント プライベートクラウドグループの中西 (@whywaita
) です。2020年9月と10月に行われたISUCON10へ、サイバーエージェント プライベートクラウドグループとしてインフラ提供を行いました。
今回はプライベートクラウドのチームが2020年のISUCONにインフラを提供した裏側についてご紹介します。本記事では準備編として、インフラ視点のISUCONについて、及び我々が行った事前準備について触れます。
その後、ISUCONの運営であるLINEの941さんに最初にお声がけさせて頂いたのが2019年2月、その後弊社内の交渉を経てISUCON10での提供が決定しました。
本当はISUCON9での提供で話が始まったのですが、私の力及ばずスキップとなってしまい、次回こそはということでISUCON10でのインフラ提供となりました。
最初に941さんとの個人的なやり取りがはじまり、インフラ視点では次のタイムラインで進みました。
過去10回の中である程度の変遷がありますが、近年のISUCONでは「参加者が問題用に用意されたVirtual Machine (VM) にログインを行い」「Webポータルから実行したベンチマーカーがアプリケーションにアクセスしスコアを決定する」という形で競技が行われています。
過去回では問題用VM上でベンチマーク用のバイナリを実行する形式も存在しましたが、近年はベンチマーク用にVMを別に用意しておき、そのVMからのHTTPリクエストを捌く形式が採用されています。
また、問題用のVMも当初は1台でしたが近年のWebアプリケーションの変遷を反映し予選本選ともに複数台構成での出題となっています。最初期はlivedoorさんを始めとしてオンプレミスでのインフラ提供でしたが、参加者が500名を超えたあたりからパブリッククラウドやパブリッククラウドを提供する事業者のインフラ提供が多くなってきました。
直近で近い構成だとISUCON8にてGMOインターネット様がConoHaを拡張した基盤で提供されていたのが珍しい例でした。 https://hoscon.gmo.jp/blog/1080/
我々は社内のエンジニアに向けてクラウドを提供する「プライベートクラウド」を日々運用しています。普段、参加者の皆さまが利用していない環境であるため、競技の進行に影響が出ないよう様々なレイヤーから検討を行いました。
ISUCON9では600チームが上限となっていましたが、2日開催が1日開催になったからと言って単純に半分の300チームとしてしまうと参加できる人数が減ってしまいます。
せっかくのお祭りですから、1日開催ではありますができるだけ多くの方が参加できるよう早い段階から検討を行っていました。
インフラとしては最大限用意できるスペックを、ということで次のようなハードウェアを用意しました。
調達時点で最も高速であったx86アーキテクチャCPUです。Discordなどで言及いただけてとても嬉しかったです。予選では1コアのみEPYC割り当てたVMでしたが、たしかに謎でしたね……。
スペック上は競技用マシンと管理用マシンともに同じものでしたが、競技用に提供するものに関しては全て同じベンダーとなるよう調整しました。基本的には起こりえないのですが、ベンダー間で何らかの性能差が出てしまうことを回避するためにこのような割り振りをしていました。
管理用マシンは以下のような用途として利用していました。
作問 & 言語移植チーム向けのVM 参加者の踏み台用サーバ (物理2台の冗長構成) クラウド基盤のコントローラ (後述) 監視用のPrometheus 問題作問用のGitHub Actions self-hosted runner
ファイアウォール: Juniper Networks SRX5400 x1 スイッチ: Huawei CE8850 100GE x2
基本的には次期基盤で利用するための予備部材で構築しました。
ストレージアプライアンス x4 VM用ストレージ実容量: 130TB all flash (NVMe) ネットワーク: 100Gbps x4 I/O Per Seconds: 約10万IOPS
2台で1クラスタとなるアプライアンス製品を2クラスタ用意しました。競技用マシンとはiSCSIで接続し、ブロックストレージとして利用していました。
こちらは実際のラックの写真です。弊社DCチームは普段からとても綺麗なケーブリングをされているのですが、「のちのちインターネットに公開するので写真を撮りたい」という話をしたところ気合が入り最高のケーブリングになりました。
今回採用したマシンは2Uに4Node搭載できるタイプであり、背面で利用するケーブルの本数も相当な数になります。
そのケーブル群を運用しやすく美しくまとめる職人芸をお楽しみください。
ベンチマーク用のVMを各チーム1つずつ用意することにより、いわゆる「ベンチ待ち」という事象が起こりえないような設計を行っていました。
これによりベンチマークのトラフィックが1つの物理筐体内で収まるため、ネットワーク機器のキャパシティによってスコアの変動が起きにくいようにすることができました。
結果として、今回は「問題用VM 3台」「ベンチマーク用VM 1台」「踏み台用VM 2台」の合計6台を1チームあたりに割り当てており、500チームが参加した予選では総計3000台前後のVMを提供していました。
BGPの経路広報ログを提供しているRIPE NCCのRIPEstatでの観測結果を引用します。5月ごろにBGPの経路広報を開始、本選終了後の10月26日ごろに経路広報を終了しました。
今回はSSHの入口のためだけのVMを各チームごとに用意しておき、インターネットからそのVMを経由してISUCON環境にログインしていただく方式を採りました。SSH踏み台と呼ばれる古来から存在する方式なのですが、近年クラウドの隆盛によって使ったことがないという方も多くいらっしゃったようでした。実際に予選開催中にはSSH接続に関するお問い合わせを数件いただきました。
そのような方がいらっしゃると想定し、予選本選の当日マニュアルには次のように踏み台を利用する
ISUCON8でのアーキテクチャを踏襲するとしてもCPU性能に本当に差が出ないのかを確認するため、UnixBenchや過去のISUCON開催のコードを用いて性能差を比較しました。
一例として、EPYCにおけるSimultaneous Multi-Threading (Intel CPUにおけるHyper Threading) を用いたときに物理コアと論理コア間で性能差がでないのかについて、UnixBenchを用いた検証結果について公開します。AMD RomeにおけるHyper-Threading（SMT）の検証.pdf
いくつかの検証結果をもとに、自チーム及び他チームの状況次第で1つのVMの性能が上下しないようなチューニングを行いました。
結果としてBIOSなどの設定変更を加味した上で"物理コア2コアと論理コア2コアを各チーム占有とする"という方式を採用しました。予選開催時は問題解答用として1コアを3台、ベンチマーク用として1コアを1台の合計4台が必要だったため、チーム占有コアを各VMに割り当てていました。
ISUCONにおいては参加者並びに利用するVMの数が多い予選こそが本番と言っても過言ではありません。多くの参加者にご利用いただいてもインフラ的な問題がでないよう議論を重ねてISUCON10インフラは完成に向かっていきます。
後編では提供するまでの道のりや、予選本選にて起きた出来事についてお届けしますのでお楽しみに。
公開されました、こちらです！
ISUCON10にインフラ提供として参加しました 提供編 | CyberAgent Developers Blog
) です。2020年9月と10月に行われたISUCON10へ、サイバーエージェント プライベートクラウドグループとしてインフラ提供を行いました。
今回はプライベートクラウドのチームが2020年のISUCONにインフラを提供した裏側についてご紹介します。本記事では準備編として、インフラ視点のISUCONについて、及び我々が行った事前準備について触れます。
インフラ提供のはじまり
私がISUCON8で優勝したのち、ISUCONコミュニティ還元のためインフラ提供として関わりたいという気持ちが大きくありました。その後、ISUCONの運営であるLINEの941さんに最初にお声がけさせて頂いたのが2019年2月、その後弊社内の交渉を経てISUCON10での提供が決定しました。
本当はISUCON9での提供で話が始まったのですが、私の力及ばずスキップとなってしまい、次回こそはということでISUCON10でのインフラ提供となりました。
最初に941さんとの個人的なやり取りがはじまり、インフラ視点では次のタイムラインで進みました。
- 2019/11/27 最初に941さんからメールをいただく
- 2019/12/17 941さんとサイバーエージェント側で初回ミーティング
- 過去開催でのインフラ規模感の共有
- サイバーエージェント側で実現するためのスペック選定
- 2020/01/30 サイバーエージェントがインフラ提供として参加確定、運営Slackに参加
- 「今年は予選を1日開催にしようと思ってるんですが、いけますかね…？」「サーバ台数が単純に倍になりますね！？」
- 2020/03/26 キックオフミーティング
- 実際に利用する物理的なキャパシティを問題チームへ共有
- 2020/03 〜 ISUCON用プライベートクラウド基盤開発開始
- 2020/09/12 予選開催日
- 2020/10/03 本選開催日
ISUCONにおけるインフラについて
ここで改めて、ISUCONにおいてインフラ提供を行う人間が何を準備しているのかについておさらいしましょう。過去10回の中である程度の変遷がありますが、近年のISUCONでは「参加者が問題用に用意されたVirtual Machine (VM) にログインを行い」「Webポータルから実行したベンチマーカーがアプリケーションにアクセスしスコアを決定する」という形で競技が行われています。
過去回では問題用VM上でベンチマーク用のバイナリを実行する形式も存在しましたが、近年はベンチマーク用にVMを別に用意しておき、そのVMからのHTTPリクエストを捌く形式が採用されています。
また、問題用のVMも当初は1台でしたが近年のWebアプリケーションの変遷を反映し予選本選ともに複数台構成での出題となっています。最初期はlivedoorさんを始めとしてオンプレミスでのインフラ提供でしたが、参加者が500名を超えたあたりからパブリッククラウドやパブリッククラウドを提供する事業者のインフラ提供が多くなってきました。
直近で近い構成だとISUCON8にてGMOインターネット様がConoHaを拡張した基盤で提供されていたのが珍しい例でした。 https://hoscon.gmo.jp/blog/1080/
我々は社内のエンジニアに向けてクラウドを提供する「プライベートクラウド」を日々運用しています。普段、参加者の皆さまが利用していない環境であるため、競技の進行に影響が出ないよう様々なレイヤーから検討を行いました。
物理構築編
今回のISUCON10は1日開催ということもあり、参加チーム数の上限について検討が必要でした。ISUCON9では600チームが上限となっていましたが、2日開催が1日開催になったからと言って単純に半分の300チームとしてしまうと参加できる人数が減ってしまいます。
せっかくのお祭りですから、1日開催ではありますができるだけ多くの方が参加できるよう早い段階から検討を行っていました。
インフラとしては最大限用意できるスペックを、ということで次のようなハードウェアを用意しました。
サーバ部門
次世代クラウド基盤用に利用する予定で検証を進めていたAMD EPYCシリーズのRome世代マシンを予定よりも早く調達しISUCON用に利用しました。調達時点で最も高速であったx86アーキテクチャCPUです。Discordなどで言及いただけてとても嬉しかったです。予選では1コアのみEPYC割り当てたVMでしたが、たしかに謎でしたね……。
- 競技用マシン: DELL PowerEdge C6525 x 24 Node
- CPU: AMD EPYC 7352 24-Core Processor x2
- Memory: 64GB x 16
- NIC: Intel XXV710 (25Gbps SFP Dual Port), bondingで利用
- Disk: オンメモリブートのため搭載せず
- 管理用マシン: SuperMicro 2124BT-HTR x 8 Node
- 性能は競技用マシンと同等
スペック上は競技用マシンと管理用マシンともに同じものでしたが、競技用に提供するものに関しては全て同じベンダーとなるよう調整しました。基本的には起こりえないのですが、ベンダー間で何らかの性能差が出てしまうことを回避するためにこのような割り振りをしていました。
管理用マシンは以下のような用途として利用していました。
ネットワーク部門
基本的には次期基盤で利用するための予備部材で構築しました。
ストレージ部門
2台で1クラスタとなるアプライアンス製品を2クラスタ用意しました。競技用マシンとはiSCSIで接続し、ブロックストレージとして利用していました。
収容ラック部門
上記の物理機材を弊社管理のラック2つに収容しました。当初は1ラックの予定だったのですが、参加者全員がフルにCPUを利用した場合にも電源容量が足りるよう万全を期すために2ラックに収容しました。こちらは実際のラックの写真です。弊社DCチームは普段からとても綺麗なケーブリングをされているのですが、「のちのちインターネットに公開するので写真を撮りたい」という話をしたところ気合が入り最高のケーブリングになりました。
今回採用したマシンは2Uに4Node搭載できるタイプであり、背面で利用するケーブルの本数も相当な数になります。
そのケーブル群を運用しやすく美しくまとめる職人芸をお楽しみください。
今回のアーキテクチャ
今回は次のようなアーキテクチャでインフラ基盤を構築していました。あまり特殊なことはせず、素朴な物理アーキテクチャで安全側に倒していました。また、ISUCON8でのGMOさん提供時の構成は大幅に参考にさせていただきました。
ベンチマーク用のVMを各チーム1つずつ用意することにより、いわゆる「ベンチ待ち」という事象が起こりえないような設計を行っていました。
これによりベンチマークのトラフィックが1つの物理筐体内で収まるため、ネットワーク機器のキャパシティによってスコアの変動が起きにくいようにすることができました。
結果として、今回は「問題用VM 3台」「ベンチマーク用VM 1台」「踏み台用VM 2台」の合計6台を1チームあたりに割り当てており、500チームが参加した予選では総計3000台前後のVMを提供していました。
ネットワークについて
今回は弊チームの管理するAS24284よりインターネット接続性を提供しました。AS24284からの経路広報情報を注意深く観察していた方がもしいらっしゃれば、ISUCONで利用したサブネットが開催前後に経路広報されたことが分かったのではないかと思います。BGPの経路広報ログを提供しているRIPE NCCのRIPEstatでの観測結果を引用します。5月ごろにBGPの経路広報を開始、本選終了後の10月26日ごろに経路広報を終了しました。
今回はSSHの入口のためだけのVMを各チームごとに用意しておき、インターネットからそのVMを経由してISUCON環境にログインしていただく方式を採りました。SSH踏み台と呼ばれる古来から存在する方式なのですが、近年クラウドの隆盛によって使ったことがないという方も多くいらっしゃったようでした。実際に予選開催中にはSSH接続に関するお問い合わせを数件いただきました。
そのような方がいらっしゃると想定し、予選本選の当日マニュアルには次のように踏み台を利用する
ssh_config(5)の例を示していました。
チーム間の性能差について
ISUCONは与えられた同一のコードを同一のスペック上で動かすことで平等にベンチマークのスコアを設定することが可能となる競技であるため、提供する際に各レイヤーでチーム間の性能差が出ないよう検証を行いました。ISUCON8でのアーキテクチャを踏襲するとしてもCPU性能に本当に差が出ないのかを確認するため、UnixBenchや過去のISUCON開催のコードを用いて性能差を比較しました。
一例として、EPYCにおけるSimultaneous Multi-Threading (Intel CPUにおけるHyper Threading) を用いたときに物理コアと論理コア間で性能差がでないのかについて、UnixBenchを用いた検証結果について公開します。
いくつかの検証結果をもとに、自チーム及び他チームの状況次第で1つのVMの性能が上下しないようなチューニングを行いました。
結果としてBIOSなどの設定変更を加味した上で"物理コア2コアと論理コア2コアを各チーム占有とする"という方式を採用しました。予選開催時は問題解答用として1コアを3台、ベンチマーク用として1コアを1台の合計4台が必要だったため、チーム占有コアを各VMに割り当てていました。
まとめ
ISUCON10でのインフラ提供に向けての準備段階に行った検討事項などについてお届けしました。ISUCONにおいては参加者並びに利用するVMの数が多い予選こそが本番と言っても過言ではありません。多くの参加者にご利用いただいてもインフラ的な問題がでないよう議論を重ねてISUCON10インフラは完成に向かっていきます。
後編では提供するまでの道のりや、予選本選にて起きた出来事についてお届けしますのでお楽しみに。
公開されました、こちらです！
ISUCON10にインフラ提供として参加しました 提供編 | CyberAgent Developers Blog
