「業務で ISUCON することになった話」について Tech Night で発表しました

はじめに

こんにちは、クラウド&ネットワークサービス部の福岡(@tkygtr6)です。 普段は SDPF クラウドの IaaS である、ベアメタルサーバー・ハイパーバイザーサービス開発のソフトウェアエンジニアとして働いています。

先日 Tech Night で「業務で ISUCON することになった話 〜課金 API の高速化〜」と題して発表しましたので、その内容について簡単にかいつまんで紹介します。

Tech Night とは社内で数ヶ月に1回開催されている、お酒を飲みながら技術でワイワイするイベントです。 各人が 5分〜20分ほどのネタを持ち寄って発表することになっていて、全体として 2〜3 時間ほどになるのが通例です。 コロナ禍になる前まではオンサイトで開催されていましたが、最近はリモートでの開催が続いています。

発表内容の概略

ISUCON1 とは LINE 株式会社が運営を行なっている Web アプリケーションの高速化についてのコンテストであり 、参加者は与えられた遅い Web アプリケーションを所定の時間内にどれくらい高速化できるかを競います。(本記事ではこの ISUCON を競技 ISUCON と呼びます。)

今回 Tech Night で発表した内容は、業務中に競技としての ISUCON に参加や開催した話ではなく、業務中に発見した遅い API の原因を特定し ISUCON の知識を用いて高速化した(業務 ISUCON)話となります。

特に発表では、以下の二点に焦点を当てて話しました。

  • どのように競技 ISUCON で身につけた知識を業務に生かすことができたのか (DB のインデックス周りの話)
  • 業務 ISUCON は競技 ISUCON とどのようなところが違ったのか (主に検証の話)

この記事では発表の内容の一部を紹介します。 本発表のフルスライドはこちらで公開しておりますので、興味のある方は是非ご覧ください。

どんな API を高速化したのか

高速化の対象になった課金 API はハイパーバイザーサービスが(内部向けに)提供している API ですので、まずはサービスの概要について説明します。

ハイパーバイザーサービスとは、vSphere や Hyper-V のようなハイパーバイザーをインストール済みの物理サーバーをオンデマンドに提供するサービスです。 また、ハイパーバイザー上で稼働する VM のライセンスについてもワンストップで提供するという機能も同時に提供しており、お客さまが自前でライセンス管理をする手間を取り除いています。 お客さまが使用した VM の有料 OS ライセンスについては、他のクラウドの使用料金と合算して請求されます。

この機能を実現するために我々クラウド事業者は、お客さまがある期間にどの種類の VM をどれくらい利用していたのかを収集する必要があります。 これを行っているのが今回高速化の対象になった課金 API です。

具体的には「2022年の8月にお客さま(テナント) A が使用した VM は?」という リクエストに対して「期間中に使用された VM X は 2つ、VM Y は1つです」と返すようなものをイメージしていただければと思います。

どのように高速化したのか

調査を進める中で、当該の API の中では、数百万レコード以上からなる巨大なテーブルに対してのクエリが発行されていて、それがボトルネックになっているようだということがわかりました。

さらに、この巨大テーブルには適切なインデックスが貼られていなさそうであるということが判明しました。 詳しい技術的な部分についてはフルスライドの P23〜P26あたりを参照していただければと思うのですが、改善と測定をループを回す中で、ただシンプルなインデックスを貼るだけでは高速化できなさそうであるということがわかりました。 したがって、クエリに含まれる JOIN 句を取り除き、さらに複合インデックスを貼ることによって、クエリを改善するに至りました。 最終的には、高速化前と比較して、30倍の高速化を達成できました。

業務 ISUCON ならではのハマりポイント

ここまでに至る道のりは一見シンプルなようですが、業務 ISUCON ならではのハマりポイントがいくつかありました。

検証のための環境構築が難しい

競技 ISUCON では商用の環境を直接操作することによって高速化を行うことになりますが、実サービスを運用する立場ではそのような乱暴なことはできません。 特に改善を加えた後に実際に速度が改善されたかどうかについての検証するためには、検証環境で DB の設定を商用とできる限り近づける必要があります。 その過程で、どうしても商用環境を用いた場合と同じような性能を出すことができないという問題が生じたため、切り分けを行う必要がありました。

切戻し方法の検証が必要

競技 ISUCON では高速化してしまえばそれで終了ですが、業務でリリースをする時には、何らかの原因で失敗した場合に備えて、あらかじめ切り戻し検証を実施する必要があります。

今回取り入れた改善の内容には複合インデックスの付与が含まれていたのですが、切り戻し時に複合インデックスの削除がうまくいかないという問題が発生したため、手順を追加する必要がありました。

余談

最終的にはクエリの最適化 + 複合インデックスを貼ることで対処したのですが、チームではインデックスの追加はしない方が良いのでは、という意見もありました。 API 自体を高速化するには過去の不要なレコードを削除するというやり方の方が簡単なのではないか、という話です。 ただ、どれくらい古いレコードを削除すれば良いか検討が必要なこと、大量のレコードを削除することにも危険があるということで、クエリの最適化 + 複合インデックスを貼るという方針で進めることになりました。 今回は没になったとはいえ、エンジニア的に「かっこいい」やり方以外の方法もあらかじめ比較検討することは大切であるということを学びました。

おわりに

「業務で ISUCON することになった話 〜課金 API の高速化〜」という題で、Tech Night で発表しました。 ISUCON によって獲得したデータベース周りのスキルが業務に活かせることを実感した一方、検証を通して信頼性を担保しながら開発する勘所を掴むことができて良い勉強になりました。

個人的な話になりますが Tech Night は入社前にも参加したことがあり、その時からいつか自分も発表する側になりたいと思っていたので、その目標を果たすことができてよかったです。 また、発表中に slack を通して普段関わらない部署のエンジニアとワイワイ交流できて楽しかったです、皆さんありがとうございました!

最後になりますが、SDPF クラウドは国内最大級のクラウドサービスです。 開発メンバーは、数千台以上の物理サーバの操作の自動化をはじめとした、技術的難易度の高い課題に取り組みつつ、日々より良いサービスにしようと邁進しております。 今回の発表で取り上げた DB のチューニングのような、長く運用されることで初めて気づくような面白い課題もたくさん転がっています。

もし我々のチームに興味を持たれた方はこちらからの応募をお願いいたします。


  1. 「ISUCON」は、LINE株式会社の商標または登録商標です。https://isucon.net

© NTT Communications Corporation All Rights Reserved.