株式会社ラフールでSREをしている伊藤です。弊社の技術的な取り組み等を理解してもらうために、不定期ですが技術的な事を書いています。

伊藤純一 / クオリティマネジメント室室長

2005年に大学を卒業し、株式会社日本総合研究所（後、株式会社JSOL）に入社。
ERP事業部でSAPプロジェクトを担当。担当領域は、SAPベーシス、インフラ、システム間連携、チームマネジメント。一部上場企業や大手外資系企業のSAP導入やSAPバージョンアップ、マーグレーション、自社パッケージ導入を担当。
その後、2011年に株式会社デファクトスタンダードに転職し、WEBエンジニア＆社内SEとして、個人向けブランド品買取サイトやオークションサイト、社内基幹システムの企画、要件定義、設計、開発、運用を担当。2012年に開発チームのマネージャーに就任し、最大20人程度のマネジメント（メンバ管理、プロジェクト管理、採用、評価）を実施。また、株式会社日本総合研究所時代に習得したインフラに関するスキルを活かし、アーキテクチャ設計やチューニングを実施。
2020年に株式会社ラフールに転職し、SREとして法人向け従業員エンゲージメントサービスのインフラ＆セキュリティ全般を担当。2020年10月にエンジニアリングマネージャーに就任。

パフォーマンスチューニングとは

そもそも「パフォーマンスチューニングって何？」と言う方も多いかと思います。
パフォーマンスチューニングとは、例えばWebサイトのレスポンスが遅く、動きがもっさりしている場合に行いますが、プログラムやWebサイト全体の処理スピードを引き上げるために色々と調整（チューニング）することです。

パフォーマンスチューニングはかなり奥が深く、パフォーマンスチューニングの沼に嵌るエンジニアも少なくありません。その結果、有志による（現在はLINE社が主催）ISUCONというパフォーマンスチューニングの腕前を競うイベントが立ち上がったりしています。（通算10回開催されており、私は過去4回連続参加）

今回はパフォーマンスチューニングの細かいテクニックではなく、パフォーマンスチューニングするにあたり私が意識している3つのことを書きたいと思います。

まず1つ目。

「推測するな、計測せよ」

パフォーマンスチューニング界隈で有名な格言です。
計測して得られた結果を元にボトルネックを分析し、改善方針を決めよということです。

当たり前のように聞こえますが、意外とこれをすっ飛ばして過去の経験だったり勘を頼りにすぐに改善をし始めてしまうケースが多かったりします。過去の経験や勘も大切ですが、思い込みによって本当のボトルネックを見落としてしまう恐れもあります。

ですので、「早くチューニングしたい！！」という湧き上がる衝動を抑えて、まずは計測することに専念するようにしています。

続いて2つ目。

スケールアウトを目指す

パフォーマンスチューニングの対策として、サーバー等の資源を増強する場合があります。その際、スケールアップとスケールアウトという2種類のアプローチがあります。

・スケールアップ：サーバーのスペックを引き上げる。
・スケールアウト：サーバーの台数を増やす。

イメージとしてはこんな感じです。

スケールアップはサーバーのスペックを引き上げるだけで手間なく実装できます。しかし、1台のサーバーで引き上げられるスペックの上限は大抵決まっているので、スケールアップに頼りすぎるといずれ頭打ちになる日が来るので要注意です。

一方、スケールアウトはサーバーの台数を増やすことで処理性能を上げているので、スケールアップよりも頭打ちになるボーダーは格段に高いです。

ですので、基本的にはスケールアウトを目指してチューニングしていくことが望ましいです。

ただし、スケールアウトするためには処理を並列実行可能にする必要があり、万が一その考慮が入っていないアプリケーションだと並列実行可能にするための改修が必要になってきます。

そのため、基本的にはスケールアップを目指し、緊急時で今すぐにでも何とかしないといけない場合のみスケールアップという選択肢を取るようにしています。

最後に3つ目。

馬がどれだけ速く走っても車に勝てない

自動車メーカーのキャッチコピーのようですが、ギリギリまでパフォーマンスチューニングする工程は、馬に鞭打って極限まで速く走らせようとしているように見えます。

ところが一歩引いてみて、選択肢の幅を広げるともっと速く走るものは自動車だったり新幹線だったり飛行機だったり数多あります。

パフォーマンスチューニングは冒頭でも触れた通り沼に嵌ると手段ではなく目的になってしまいます。

ですが、より大局的な目線で見た場合、パフォーマンスチューニングはユーザーにより快適にシステムを使ってもらうための一つの対策であり、快適にシステムが使えるのであれば必ずしもパフォーマンスチューニングをゴリゴリにやる必要はありません。

例えば、データベースや言語を別のものに置き換えてみたり、作り込んでいる機能を既に世の中に出回っているサービスに載せ替えてみるとか、工数やコストがかかる可能性があるものの、大きなブレイクスルーを起こすかもしれません。

ですので、常に大局的な目線を忘れないようにし、情報のアンテナを張り巡らして技術の進化をキャッチアップするように意識しています。

ビジネスへの応用

ここまでエンジニア観点でパフォーマンスチューニングについて書いてきましたが、ちょっとだけビジネスへの応用を考えてみようと思います。

「パフォーマンスチューニングとビジネス？？そんなの結びつかないでしょ」と思う方もいるかもしれませんが、少し待ってください。

ビジネスにおいて大量のオペレーションを回さないといけない時ってありますよね？

これってWebシステムが大量のアクセスを受けた場合にいかにきちんと捌くかに似ていると思いませんか？

大量のオペレーションを捌くためのコツとして、先ほどのパフォーマンスチューニングの時に意識している3つのことが使えるのでは無いでしょうか。

まず1つ目の「推測するな、計測せよ」に従うと、オペレーション全体でどこがボトルネックになっているかを可視化し、どのステップを重点的に改善しないといけないかをまず明らかにします。いきなり業務効率改善だと張り切ってミクロの改善をしても的外れになることがあります。

続いて2つ目の「スケールアウトを目指す」に従うと、少人数で何とかしようとせず、大量の人員で手分けして捌くようにします。システムも同じですが、大量の人員で手分けするためには、いかに速やかに作業に入れるか、極力誰でも理解できるようなマニュアルを用意しておくか、具体的に何をすればいいのかを明確にしておく必要があります。

スケールアウトを目指すことの副産物としては、誰か1人が抜けたとしてもオペレーション全体への影響は軽微で済みます。もし少人数でオペレーションを回している場合、1人が抜けるだけで途端に破綻することも少なくありません。

最後3つ目の「馬がどれだけ速く走っても車に勝てない」に従うと、何でもかんでも人力で何とかしようとせず、投資対効果が見込めるのであれば積極的にツールや新しい手法を導入し、効率化を積極的に図りましょう。

オペレーションをいかに効率良く回すかの考え方については、個人的に以下の書籍に大きな影響を受けております。興味がある方は一読してみるといいかと思います。

まとめ

今回はパフォーマンスチューニングについて大局的な話を書かさせていただきました。細かいテクニックは上げ出したらキリがないので、そのあたりは今後の記事で触れられればと思います。

拙い文章となってしまいましたが、最後まで読んでいただき誠にありがとうございました。次回記事も読んでいただけると幸いです！