オートマチックの功罪

日本国内を走る車の約98%以上はAT車と言われており、MT車の割合は2%に満たないと言われております。
敢えてMT車を選ぶ人も極々少数いますが、なぜその一部の人たちはMT車を選択するのか聞いてみると、おおよそ次のような答えが返ってきます。

  1. 自分で車を操作している感覚が好き。運転が楽しい

  2. 燃費がいい

  3. 微妙な速度調整がやりやすい

  4. メンテナンスが楽である

1つ目については個人の感性なので、「それが好きだから!」と言われたらそれ以上は何も言えないですが、2~4については果たして本当にそうなのでしょうか?
ひと昔前であれば確かにその通りだったかもしれません。が、技術が進歩した昨今、AT車でも燃費の面で負けていないこと、微妙な速度調整もうまくやってくれるようになってきたこと、そもそもトランスミッション周りのメンテナンスをさほどしなくてもよいことなど、技術革新によりその優位性も希薄になってきているのではないかと感じています。
事実として、2~4のメリット故にMT車が多かったバスやトラックなども最近はAT車が普及してきています。
さて、ここで車の話をしたいわけではなく、システムインフラも昨今はある種のオートマチックな設定が普及してきているということを私はお伝えしたいです。
『Zero Administration』というワードをMicrosoftは提唱しておりますが、維持管理にかかるコストを低減させよう、それを実現する設計ポリシーで製品を作ろうという思想だそうです。

発端

KENTEMではデータベースとしてSQL Server(Azure SQL Database)を利用しているプロジェクトが多いです。
以前のプロジェクトにて100万件程度のデータから数十件のデータを抽出するクエリ実行にて、初回の実行だけ1分程度待たされるが2回目以降は1秒未満で結果が取得できるという事例がありました。

SET STATISTICS TIME ON
SET STATISTICS IO ON
SET STATISTICS XML ON

/* 問題のクエリ */ 
SELECT
     *
FROM
    ・
    ・
    ・

「キャッシュの生成に時間がかかっている可能性がある」と思い、キャッシュとプランを削除して実行してみたものの、

SQL Server parse and compile time:
   CPU time = 0 ms, elapsed time = 11 ms.

11 msであればキャッシュが原因ではないですね・・・。
いろいろ調べてみると、初回実行時に「_WA_Sys_XXXXXXXX_YYYYYYYY」というDBオブジェクトが生成されており、これを削除して再度上記クエリを実行してみると、

SQL Server parse and compile time:
   CPU time = 484 ms, elapsed time = 47951 ms.

1分近く待たされることから、このオブジェクト生成に時間がかかっていることが判明しました。
このオブジェクトが存在している状態では一瞬でクエリが完了することも確認ができました。

このオブジェクトが何者かを調べてみると『自動的に生成された統計情報』でした。
つまり、あるクエリの初回実行時に統計情報を生成し、その生成に時間がかかっていることが分かりました。
統計情報とは簡単に言えば、次回以降に同一の条件で検索を行う場合にDBのオプティマイザが検索の方法(実行計画)を判断するための情報となります。
カレントバージョンのSQL Server(Azure:12.x、SQL Server 2019)では統計情報は自動作成・自動更新される設定になっており、特にデータ量が多大なテーブルにお初のクエリを投げるとこういう事態が起こり得ることになります。
テーブルに対して各カラムを抽出条件としてクエリを事前に1回でも実行しておけばよいかもしれませんが、そもそもヒント句により実行計画を固定しているのであれば統計情報の必要性はないのではないでしょうか。

Zero Administration

先の事例について、古いSQL Serverバージョンでは統計情報は手動作成および手動更新の設定であったようです。
しかしながらいつからかそれも自動となり、特に利用するエンジニア側が使い方に合わせた細やかな設定をせずともある程度の動作をしてくれるZero Administrationの考えが反映されているのではないかと感じます。
そもそも先に述べた「ヒント句により実行プランを固定」というクエリを書く人は最近少なくなってきた気がします。
「そんなにマニアックな設定を頑張らなくても、インフラ側である程度のことは勝手に対応してくれる」という感覚でしょうか?

pros and cons

技術の台頭によってある程度のことはオートマチックに(自分が関与せずに)やってくれるから、本質的にやるべきこと(例えばビジネスロジックそのものなど)に集中するという考え方はビジネスの世界で決して間違っているわけではないと思います。
ですが、それによってシステムの勘所が分からなくなっていることもまた事実ではないかと感じることがあります。
「それはおじさん世代が好きなだけの昔話だ」と言われればそれまでかもしれませんが、少なくとも昔は手動でやっていた作業を自動化しているエンジニアが現在も存在するわけで、どういうメカニズムになっているのかを知ろうとする行為はエンジニアにとって興味深いものであっていいと私は感じます。
興味を感じたら是非そんなスタンスで臨んでみてください。
自分でシステムを操っている感覚が好き!それが楽しい!! そんなエンジニアをお待ちしています。

KENTEMでは、様々な拠点でエンジニアを大募集しています!
建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。
recruit.kentem.jp career.kentem.jp

  翻译: