みなさんこんにちは。ISUCON4 出題担当チームの mirakui です。
2014年11月に行われた ISUCON4 本選ではテコラスさん提供のホスト上に用意された VM で競技を行いました。今回、本選の VM に似た環境を再現する AMI を用意しましたのでご紹介いたします。
AMI
本選環境を再現するために、2つの AMI を提供します。1つはチューニング対象アプリケーション用の AMI 、もう1つはベンチマーカー用の AMI です。
- アプリケーション AMI
- ami-86e8e287
- ベンチマーカー AMI
- ami-84e8e285
アプリケーション AMI は、本選で参加チームに3台ずつ提供された VM とほとんど同じ内容です。
ベンチマーカー AMI は、ベンチマークサーバを再現するもので、 benchmarker の実行ファイルと、本選で実際に用いられた動画ファイルのセット（13GB程度）が入っています。
推薦環境
本選の競技環境に近づけつつ、安定したスコアを得るため、以下の環境で試すことを推薦します。
アプリケーション用インスタンス（1〜3台）
- インスタンスタイプは c3.large
- ただし、カーネルパラメータによって 2 cpus / 1GB memory に制限されている（後述）
- EBS は gp2 (general purpose SSD) 80GB
- standard (magnetic) タイプだと性能の個体差が激しく、ガチャ問題が発生するため
アプリケーション用インスタンスは1台から3台のうち好きな台数を立てて下さい。初期状態の参考実装では複数台のアプリケーション用インスタンスがあっても無意味なので、最初は1台だけで充分でしょう。
なお本選では、VM3台のうち1台が 1 cpu 、のこり2台が 2 cpus で提供されました。この条件を再現するために、アプリケーション用インスタンスを3台立てる場合は、そのうち1台の /etc/grub.conf を編集して maxcpus=1 にしてください。詳細は後述します。
ベンチマーカー用インスタンス（1台）
- インスタンスタイプは c3.2xlarge (8 cpus / 15GB memory)
- 合計13GB程度の動画ファイルをメモリに展開する必要があるため
なお、インスタンス間のネットワークレイテンシを安定させるため、ベンチマーカー用1台およびアプリケーション用3台のインスタンスは、すべて同じ Availability Zone で起動してください。
もっとこだわる方へ
AWS に詳しい方は、上記の推薦環境に加えて、 Placement Group や Dedicated Instance の利用、インスタンスタイプの変更、 EBS Optimized オプション、Provisioned IOPS EBS 等を試してみてもいいと思います。そのようなスコアをブログ等で公開する場合には、利用したテクニックを明示しましょう。
カーネルの起動パラメータによる性能の制限
EC2 は、性能の高いインスタンスほどネットワークや CPU 等の性能が安定するように作られています。本選では非常に貧弱な VM 環境（1-2 cpus / 1GB memory）があえて使われたのですが、これを再現する EC2 インスタンスとして t2.micro などの貧弱なインスタンスタイプを使ってしまうと、性能が安定せず、スコアの再現性が非常に低くなることが予想されます。
そのような事態を避けるため、今回の AMI 提供では、推薦環境として c3.large という比較的高性能なインスタンスを指定し、その代わりにカーネルの起動パラメータで CPU 数とメモリ容量を制限するという方式を採用しました。
カーネルの起動パラメータは /etc/grub.conf に記述してあります。
（/etc/grub.confから抜粋） kernel /boot/vmlinuz-2.6.32-431.29.2.el6.centos.plus.x86_64 root=LABEL=ROOT ro consoleblank=0 console=ttyS0 maxcpus=2 mem=1G
「maxcpus=2 mem=1G」の部分で制限を指定しています。この maxcpus を 1 に変更してインスタンスを reboot することで、CPU 数を 1 に減らすことができます。
ベンチマークの実行
インスタンスを立てたら、ベンチマークを実行してみましょう。各インスタンスには、インスタンス作成時に指定した鍵ペアを利用し、 root ユーザで SSH ログインすることができます。ログインしたら isucon ユーザに su してください。
実際の本選とは異なり、ベンチマーカー用インスタンスから benchmarker の「bench」コマンドを利用してアプリケーション用インスタンスに負荷走行を実行します。本選競技で利用した「remote」コマンドは使えないので気をつけて下さい。
（ベンチ―マーカー用インスタンス）
$ su - isucon
$ pwd
/home/isucon
$ ./benchmarker bench --hosts=XX.XX.XX.XX --workload=1
[2014-12-28 13:13:13] アセットデータを事前ロード中です...
[2014-12-28 13:25:04] 初期化エンドポイントへ POST リクエストを送信しています...
[2014-12-28 13:25:05] 初期化完了
[2014-12-28 13:25:05] ベンチマーク開始
[2014-12-28 13:26:05] ベンチマーク完了(1m0.000371136s)
[2014-12-28 13:26:25] レポートの検証開始
[2014-12-28 13:26:25] レポートの検証完了
[2014-12-28 13:26:25] 結果を JSON 形式で標準出力へ書き出します
[2014-12-28 13:26:25] 得点: 1000.00 (加点: 1000.00 / 減点: 0.00)
{
"errors": {},
"score": {
"fail": 0,
"success": 1000.00,
"total": 1000.00
}
}
負荷走行の初回は、メモリに 13GB の動画ファイルを読み込むので、「アセットデータを事前ロード中です...」が表示されてから5〜10分程度かかります。2回目からは OS のページキャッシュが利用されるため、30秒程度で負荷走行が開始されるようになります。
「--hosts」オプションでは、負荷走行を行なう対象のアプリケーション用インスタンスの IP アドレスをカンマ区切りで指定します。IP アドレスはベンチマーカー用インスタンスから 80 番ポートが疎通するものにしてください。複数の IP アドレスを指定した場合は、その中からラウンドロビンで切り替わりながらリクエストされます。
「--workload」オプションでは負荷走行の並列度を 1 から 8 の中で指定することができます（デフォルトは1）。
「bench」コマンドの help は以下のコマンドから参照することができます。
$ ./benchmarker help bench
実際の本選でもそうであったように、アプリケーション用インスタンスにもベンチマーカー用インスタンスのものと全く同じ benchmarker のバイナリが同じパスに置いてあります。これを使って負荷走行をローカルに対して実行することができますが、動画セットがベンチマーカー用インスタンスのものとは異なるので、あくまで動作確認での利用にとどめてください。
その他の操作方法
参考実装の切替方法や、アプリケーションの使い方などについては、本選とまったく同じです。以下のマニュアルを参照して下さい。
レギュレーション
レギュレーションは本選のものに準拠します。
ソースコードの公開
本選の参考実装およびベンチマーカーのソースコードは以下の GitHub リポジトリで公開しています。
注意事項
ISUCON4 本選の解説と講評 でも書いたように、本選では1チームに与えられた3台の VM は1つの物理ホストに入っているという状況でした。このため、VM 間では非常に低いネットワークレイテンシが得られました。EC2 でも Dedicated Instance （ハードウェア専有インスタンス）を利用することで近い状況にすることはできますが、比較的高価なオプションのため利用は自己責任でお願いします。先にも書きましたが、AWS の様々なオプションを利用してパフォーマンスの最適化をした際のスコアをブログ等に書く場合は、利用したテクニックを明示しましょう。ISUCON は AWS に詳しい人のためだけのものではないので、AWS のオプションを駆使して本選の再現性を追求するよりは、あえてセットアップが簡単な最低限の設定を推薦環境としました。
おわりに
AMI について質問や不具合などありましたら、isucon4 リポジトリの issue か、 @mirakui までご連絡ください。
それでは、本選に参加された方も、そうでない方も、ぜひ ISUCON4 の問題をお楽しみ下さい！
