「いったい何秒かかるんですかね」
「いつまで待てばいいんですかね」

数千万・何億件ものデータを格納するデータベースに対して検索を行う時、こういう台詞を「言う・聞く」事があります。数千件や数万件の規模であれば瞬きする程度で結果が表示されますが、数千万や「億」といった単位に差し掛かると、データベース性能は「僕らの期待値」から徐々にずれ始めていきます。

こんにちは、増木です。
第2回目からは、実際に私達が経験した事象やそれにまつわる内容をご紹介します。今回は、私達インフラエンジニアが非常に多く意識する「期待値」に関する話題をお送りします。

期待値とは

私達の日常生活には、様々な「期待値」が存在しています。
簡単な例でいいますと、

• 水道の蛇口をひねると、何秒も待つことなく、水が流れ出てきます。
• 部屋の照明スイッチを押すと、何秒も待つことなく、明かりが灯ります。
• スマートフォンの画面アイコンをタップすると、何秒も待つことなく、アプリが動きます。

人生で初めてこれらを経験する時は、「反応するまでの時間」は当然知りませんね。逆に恐らく何秒待ったか、なんて最初はあまり気にもしていないでしょう。スマートフォンの例であれば、どんな画面が表示されるのかワクワクしているに違いありません。
ですが、このような経験を日々積み重ねていくと「あ、なんか引っかかるなぁ」とか「このアプリ遅いなぁ」と感じる事が増えてきます。

それは無意識のうちに「そもそもこの動作は何秒くらいで終わるはず」という自分自身の経験に基づく期待値が生み出されているから、と私は考えます。それは一般生活でもエンジニアとしての経験としても同じです。

僕達の世界

自分が構築したサーバーに対してWebブラウザを用いた表示試験を試みた時、なんだかもっさりした動作になった・・・という経験はよくある話です。

原因はなんでしょう?
画面へ表示される画像データが多すぎた? 予算都合でメモリやCPU性能を確保できず処理に時間がかかっている? インターネット回線が混雑していて通信に時間がかかっている? あ、そもそもサーバーの設定が間違ってたよ・・・なんて事があります。

サーバーを運用する、という事は「いくつもの部品が相互に影響しあって動作する」という事です。素晴らしい性能を誇るサーバーを購入しても、インターネット回線が劣悪では宝の持ち腐れになります。
私達は「どんな要素で構成されているのか」を可能な限り把握し、それらを自分達の手の届く範囲において最善を尽くす。インフラエンジニアとしてそう思うのは当然の事でしょう。

ですが、そのような志高きインフラエンジニアでも「数億件以上のデータを集めて検索してパパパっと表示したいんでヨロシク」という無慈悲な提案が手渡された時にはどうするでしょうか。経験を積み重ねてきたエンジニアであれば様々な提案が可能です。

例えば、

• プログラムを見なおして最適なロジックを考えましょう
• データベースサーバーを分散させましょう
• 予算の許す限り高性能なサーバーを購入しましょう

現在では様々な技術がありますので、このような無慈悲な提案に対しても対応は可能でしょう。
もちろんこのような複数の提案ができるようになるには、そのエンジニアがどれだけ経験してきたか、という点に大きく依存します。
大きな組織であれば役割分担も明確になり、分業する事によりチームとしての提案が可能になるかもしれませんね。

ですが、世の中はそのような案件ばかりではありません。
カットオーバーを迎え順調に稼働を始めたと思っていた(ここ重要)Webサイトが、お客様の期待値とは遠くかけ離れた状態(呆れる程に表示が遅い)となり、クライアント様より業火の如くお怒りの電話が入電・・・という事の方が多いかもしれませんね。本当に全く笑えません。

お客様が「こうだろう」と考える期待値とは、私達インフラエンジニアが感じるそれとは大きく違う場合が多くあります。
それはインフラエンジニアとしての常識からすれば「まさか」となりますが、実際に日々利用するお客様の立場からすると「そんな馬鹿な」となるわけで、このギャップをどのように埋めていくか、それが「お客様を見る」という事なのです。

インフラエンジニアとして努力するべき領域は数多くあります。その領域は経験した業務と密接な関係がありますので、逆に言うと、どのような組織・エンジニアにでも「不得意」な領域はどうしても存在します。

新しいウェブシステムを開発すると、どうしても運用は経験しながら積み上げていく必要があります。予想外のトラブルもあるでしょう。
しかし私達はこうやって苦い経験とそれへの対処を繰り返し行うことにより「不得意」「未経験」を小さくしていきます。この繰り返しこそ、その組織に個性を産み、強くしていく事に他なりません。

ミリ秒への挑戦

話を元に戻しましょう。
そのような経験を積み重ねても改善しにくい事象もあります。エンジニア達の経験では解消できない問題。今回の内容では、「いったい何秒かかるんですかね」と言われた、データベース応答時間に関するものです。

データベース応答時間を短くするには何が必要でしょうか。
単純に言えば「CPU性能」を向上させるのが有効と言えるケースがあると思います。

ですが、「数千万、数億件」というデータを取り扱い始めると、重要となるのは「CPU性能」よりも「記憶装置」と言えます。
数億件ものデータを格納する「記憶装置」の動きが遅ければ、どれだけ「CPU性能」を向上させたとしても大きな改善はない可能性が高い。「記憶装置」を改善する事が現在においては最も優先するべきポイント、と考えていますし実際に私はこの考えに基づいてシステムを設計しています。

この考えに基づいて、当社にて改善を進める手法の1つに、半導体チップを利用したストレージ装置の利用があります。
従来は、ハードディスク装置を様々なデータを格納する事が当たり前としてサーバーを運用しておりましたが、このハードディスクを利用する事がシステム全体の動作を妨げる要因になりつつあります。

一般の方々からするとハードディスクは「高速」というイメージがありますが、私達インフラエンジニアからすると、「数百万件・数千万件・数億件」という規模のデータを取り扱うレベルに達すると、もはや高速という表現は適しません。

ハードディスクは円盤状の磁気ディスクを高速に回転させ、磁気ヘッドを物理的に移動させながら情報の記録・参照を行います。このような物理的な動作がある以上、どこまで処理速度は上限に到達し、お客様の期待値からずれ始めていきます。

この問題を解決するにはいくつかの手法がありますが、この数年間で特に注目を浴びているのが、先ほど触れました「半導体チップを利用したストレージ装置」です。パソコン業界に詳しい方であれば「SSD」(Solid State Drive) と言えばご理解いただけると思います。
ちょっと極端な表現をしますと「USBメモリなどの仲間」といえばおおむねご理解いただけるかもしれませんね。

もちろん、一般に電気街で販売されているSSDを利用する事はありません。私達が利用するのは、「エンタープライズ向け製品」に属するサーバー用途の製品となります。
これらはハードディスク装置と比較して驚く程の高速性能が発揮されます。2倍? 3倍くらい? いえいえ「数十倍以上」という表現が適しています。物理的に部品が動くわけではないので、故障率もぐっと低くなります。

世の中には「まだ本番サービスでの利用は早いのではないか?」と判断する方もいるかと思いますが、当社の製品である Synergy! のマスタデータベースにも同様の製品を採用しており、その利便性は製品としての信頼性に何ら問題がないという結論に達していて、今後も導入が進むものと考えています。

様々なシステムが世の中には存在しており、様々な問題を抱えていると思います。
今回ご紹介した技術については、その問題のいくつかを改善する可能性があるかもしれません。
予算の問題もあるでしょうが、このような製品を検証し採用するという事もインフラエンジニアとしての経験を増やし組織としての提案力を向上させるきっかけになると考えています。

※記載されている内容は掲載当時のものであり、一部現状とは内容が異なる場合があります。ご了承ください。