ソフトウェア・基盤システム部の三吉(sankichi92)です。
株式会社アークエッジ・スペースは、11月25日に開催された Web サービスのパフォーマンスチューニングコンテスト ISUCON 13 にゴールドスポンサーとして協賛しました。
また、スポンサー特典の参加確定枠で、namachan10777、sankichi92、sksat の ISUCON 初参加1メンバー3人で「HEAVIEST OBJECTS IN THE UNIVERSE (./target)」というチームを組みました。 社内からは他に、KOBA789 がチーム「ソレイユ」のメンバーとして参加しています。
この記事では、企業スポンサーとして協賛した背景や、ISUCON 初参加の振り返りについて書いていきます。
企業スポンサーについて
我々アークエッジ・スペースは、「誰もが衛星によるビジネスが可能な未来を」をミッションに、人工衛星の開発・実証をはじめ、あらゆる宇宙ニーズに応えるための事業モデルを展開するベンチャー企業です。
人工衛星の開発においてもソフトウェア技術は広範に用いられており、特に、我々の衛星管制システムは一般的な Web サービスと変わらない技術で構成されています。 そして、宇宙空間という限られた計算・通信リソースしか利用できない環境ならではのソフトウェアパフォーマンスの課題がたくさんあります。 宇宙業界が産業として成長していくためには、ISUCON 参加者のようなソフトウェアエンジニアの皆さんの力が不可欠なのです。 このことについては、参加者への応援メッセージにも書いています:
しかし、衛星開発におけるソフトウェアの課題に関して、広く知られているとはいえません。 そこで、ISUCON に参加するようなソフトウェアエンジニアの皆さんに我々のことを知ってほしいという思いから企業スポンサーとして協賛しました。
企業賞の「打ち上げ成功賞」では、賞品としてノベルティTシャツに加え、有明オフィスの「衛星開発現場見学ツアー」を用意しました2。 見学ツアーを通して、衛星開発を面白いと思っていただけたら、また、衛星開発が普段のソフトウェア開発と地続きであると感じていただけたら幸いです。
ソフトウェア技術に関する我々の取り組みについては、以下の記事をご覧ください:
また、12月12日(火)には「人工衛星の開発現場でLT大会 〜Rust Christmas〜」と題して、Rust に関する LT 大会を開催予定です。 こちらのイベントでも衛星開発現場の見学を実施します。 少しでも Rust に触れていればどんな LT でも構いませんので、ネタをお持ちの方はぜひご参加ください:
初参加の振り返り
ここからは、スポンサー特典枠で参加したチームの振り返りです。
結果から書くと、「再起動後のスコアが75%以下であったため」fail でした。 競技時間中の最終スコアは 33,673 で、仮にこのスコアで順位がつけば 57 / 694 位というあたりです。
実のところ、終了の1時間ほど前から原因不明のアプリケーションエラーで整合性チェックが通らなくなっており、なんとか最終スコアを記録できたのは終了2分前を切ってからでした。 当然、自分たちの手で再起動して動作確認することはできておらず、チームでも追試は通らないかもという話はしていました。 (全チームスコアが公開される前にリソースを削除してしまっていたので、スコアが下がった原因はわからないままです。)
fail という結果は残念ですが、チーム結成当初の「本番を楽しめるようになる」という目標は達成できており、終盤の状況もこれはこれで ISUCON 本番らしい経験だったかなと思います。
事前準備
事前準備として、ISUCON 12 予選と ISUCON 11 予選の問題を使ってチームで練習しました。 練習環境について、ISUCON 12 予選は KOBA789 が開発した ISUNARABE、ISUCON 11 予選はクーポンが利用できるさくらのクラウド上に公式で紹介されている手順で構築しました。
初回の練習で、KOBA789 から ISUNARABE の使い方、本番の流れや重要なポイント、具体的な計測・改善方法といったノウハウを聞けたのが大きかったです。
これらの練習を通して、共通して利用する計測手段や技術スタック、序盤の流れ、おおよその役割分担を決めました。
本番当日
当日使用したリポジトリは以下です(ただし、前述の通り終了直前は慌てていたので、最終スコアのコードは main ブランチとは一致しません):
次に、メンバーそれぞれが主にやったことを挙げます:
- namachan10777
- sankichi92
- sksat
感想
namachan10777
私は比較的Rustアプリケーションが得意だったのでひたすらsrc/main.rs
を見ていました。
時系列としては以下の通りでした。
10:20
デプロイ環境整備、アプリケーションコード読み始め11:30
nginxのログからボトルネックを探してデプロイする環境が概ね出来た12:00
これとにかく/api/user/.+/icon
が遅くね?とチームが気がつく13:00
ハッシュ値をインメモリキャッシュしつつ画像本体をローカルのファイルシステムに逃すが、バグってる14:30
アイコンのキャッシュができた気がする- 普通に罠で出来ていない
15:00
stats周りのクエリでuser
をjoinする必要がないことに気がつき、sankichi92に相談し修正。割と効いた16:30
アイコンのキャッシュを/initialize
でパージしていないことに気づく。修正16:40
commentとreactionのGETを高速化することを考える17:00
スキーマ変更やクエリの大規模な修正をせずとも、インメモリキャッシュで改善出来そうなので実装17:00
盛大にバグり始める。整合性チェックが失敗し出す17:30
どうもベンチマーカー(に加えてフロントエンド)が投げてくるJSONがinvalidらしいと気がつく17:40
ロールバックしてもどうにもならず混乱。構成変更を試しだす17:55
急にベンチ結果が出る。33000点ぐらい出る。祈りだす
バックエンドの経験が長いsankichi92がインフラ構成とDBチューニング、
常日頃CMakeLists.txt
やCI/CDを触っており対応力の高いsksatがPowerDNS、
普段からRustでWebバックエンドを書いている私がアプリケーションサーバという役割分担はかなり良かったように思います。一人でアプリケーションを書いていたのでコンフリクトも起こらず、また他のメンバーの働きでアプリケーションサーバの改善に集中出来たのは良かったです。
私自身の反省点としては実装の遅さ、SQLへの習熟が足りなかったかなと思いました。
初めてのISUCON出場でしたが動きとしてはそこまで悪くなかったかなと思います。
今までと異なりフレームワークがactix
からデファクトになりつつあるaxum
に変わったのも助かりました。
実装力を10倍に高めて来年は上位に食い込みたいです。
sankichi92
チームの使用言語は Rust でしたが、Rust を書いた経験がほとんどなかったため、主に DB 周りを担当していました。
実のところ、アプリケーションコードを書くつもりで、普段使いの M2 MacBook Air とは別に x86 のビルド環境を AWS に用意3して練習の際のコードがビルドできることまで確認していたのですが、いざ当日ビルドしようとすると空きディスクが足りなくなった4ため、その時点で諦めてアプリ以外をやることにしました。
結果として、他のメンバーが比較的苦手な DB のチューニングに注力できたのと、ベンチマーカ実行時の htop コマンドの結果を見ながら、落ち着いてサーバ分割の方針決定・実行ができたのはよかったかなと思います。
N+1 解消等のアプリケーション改善ができなかったのが心残りなので、次回参加までには Rust を手に馴染ませておきたいです。
sksat
僕は普段は Cargo.toml
と build.rs
ばかり書いているような人間なので、実はアプリケーションコードも DB 周りもあまり何をどうすればよいかわからない、という状態からのスタートでしたが、結果的に今回の問題の大きな特徴の一つであった DNS 周りに集中できたのはよかったです。
まず、PowerDNS という実装は初めて目にしたので、それを調べる過程でさくらインターネットさんの JANOG51 での発表に辿り着き、今回の作問担当もさくらインターネットさんであることには、デプロイがちゃんと回るようになった少し後に気付きました。 https://www.janog.gr.jp/meeting/janog51/wp-content/uploads/2022/12/janog51-dns-nagano.pdf
そこで、この発表を元に dnsdist を PowerDNS の前段に噛ませることを考えたのですが、PowerDNS と dnsdist の設定の書き方にだいぶクセがあり、非常に悩まされました。
dnsdist の ACL の存在に気付くのが遅れて、なぜかサーバ内で dig
を叩いても名前解決できていそうなのにベンチマーカでは名前解決に失敗してしまう、と思ってしまったのと、ちょうどそのタイミングでベンチマーカの調子が悪くなってしまったのもあって、原因調査にだいぶ時間をかけてしまったのが痛かったです。
そして、ようやく原因調査と設定の書き方が分かってきたと思ったら終了1時間前で、色々試そうとはしたもののベンチが盛大にコケていて本番環境には投入できないまま競技終了、というかんじでした。 終わってみると、上位チームはシンプルな DNS サーバを実装してしまうという、実務であれば絶対にありえない方法で解決しているところが何チームかあったようで、柔軟な発想ができるようになりたいなと強く思いました。
あとは、他のメンバーの Apple Silicon でのビルド環境の整備をやり切れなかったこと5と、デプロイスクリプトの用意が不十分だったり遅かったりして当日の時間を結構奪っていたのが心残りです。Web サービスに慣れるのも含めて、個人的に素振りをしておきたいですね。
ということで、いい結果は残せなかったものの、元々の想像よりはずっと ISUCON を楽しむことができました。色々と悔しさがあるのは楽しめたことの証だと思っています。運営のみなさん、本当にありがとうございました!
おわりに
アークエッジ・スペースでは、ソフトウェアのパフォーマンスチューニングに関心のあるエンジニアはもちろん、世界最先端の人工衛星で共に人類の "Edge" に挑戦する仲間を募集しています!
- 私 (sankichi92) は、前職で2回社内 ISUCON の経験があるので、何も知らないというわけではありませんでした。↩
- 打ち上げ成功賞は、13,015 → 60,788 (467%) のスコア上昇を達成した「チーム7年目」が受賞しました。メンバーの皆様と衛星開発現場見学ツアーでお会いできること楽しみにしています!↩
- x86 以外でのビルドには対応しないことを事前にチームで決めていました。↩
- ビルド速度のために CPU は積んだものの、ストレージを出し惜しんでしまい、チーム名の由来を身にしみて実感する結果となりました。↩
-
とはいえ、手元のノート PC で
cargo build --releasde
すると目の前のあらゆる操作も重くなってしまうので、x86_64 環境だけで生活している僕も当日は別途ビルド用のサーバを用意して使っていました。どちらかというと全メンバーが使いやすいビルド・用サーバを用意する仕組みを作るべきかもしれません。↩