あるクラウドエンジニアからの私信　第七便

「外れデバイスがあるのではないのですか？」
頂いたリクエストを読み進めていった先に最後に書かれていた一文。
当初、何を言っているのか？とわからなかったが、次第に理解していくと事の重大さに気づく。
少なくとも筆者よりクラウドというものを知っていると、書かれた一文とも理解していくにつれ、担当させてもらう怖さを感じる。
そう、この担当させてもらっているクラウドの機能について、お客様のほうが経験値も知識も上という案件だ。
とある計算する機能を使用したところ、通常8時間で終わる計算が倍以上の24時間かかってしまうことが多いという内容だった。
ただし、10回のうち8回の時もあれば、再起動後はその10回のうち6回の時もあると。
そんな証拠たる資料まで送付してくれていた。

一方、確かにクラウドといえど、どこかにたくさんのハードウェアが集合するデータセンターが存在する。
あれだけの量のハードウェアがあれば、その機能や性能にムラが生じるという仮説は成り立つ。
しかし、一応念のため調べてはみたが、そんなことは公式ドキュメントに記載はされてはいない。
「外れデバイス」という単語だけが独り歩きしている。
調査をしようと前に進んでも、その単語の重力に足をつかまれる。
本当に「外れデバイス」のムラがあるのでは？と。
であれば、どう説明しようか？
しかし、そんなことがあってはならない。
不安定な気持ちから、調査するというベクトルを定めることができていない。
「正常」「異常」という二元論のほうがまだ楽であっただろう。
「外れデバイス」のムラは、調査しようとする気持ちまでムラを作ってくれている。
まるで、自分がこのリクエストを担当する「外れデバイス」ならぬ「外れ担当者」のような気分だ。

まず、その計算されていた時間帯においてデータセンター側のハードウェアの障害を調査してみた。
あれだけの量のハードウェア、CPUやメモリーやハードディスクがあれば、何かしら壊れてしまうことは明らかだ。
資格取得のための技術書で読んだ内容を思い出していた。
ハードウェアの故障での取り換え作業は、その都度ではなく「今日はここからここまでのブロック」を「明日はここからここまでのブロックを」と、ハードウェアが壊れることを前提にハードウェアの交換作業がされていると。
しかし、計算されていた時間帯全てで、ハードウェアの故障はなかった。
まだハードウェアの故障があったほうが楽にことが進められるのにと、身勝手な気持ちが芽生えてしまう。
SLA順守のための返信をこちらからさせてはもらったが、その性能にムラがあるかもという疑念から逃れることができない、説明できない恐怖が付きまといながら送信ボタンを押しはしたが、無駄な徒労感だけが残っていた。

ハードウェアの故障はない。
次に疑うのはソフトウェアだと、弊社側で運用している、つまりは責任の範囲として弊社側に属すソフトウェアの障害等の調査をしてみた。
しかしというか、やはりというか、弊社側に属すソフトウェアの障害など存在しないことがわかった。
弊社のデータセンター側ハードウェアとソフトウェアの両方に問題はない、となれば連絡してきたお客様サイドの問題であろうと、鬼の首を取るというより、藁をもつかむ思いでその事実たる証拠を全面に、お客様へ送信した。
「弊社側で提供しております、ハードウェアとソフトウェアに問題はございませんでした。そのため、お客様で使用されている計算ソフト内の不具合で本事象が発生していると思われます」と。
これで、お客様が直面している外れデバイスのムラを起因とした、この不安定な気持ちが終わることを祈って。

次の日、自分の浅はかな態度、思考に自分でもうんざりしてしまった内容の返信をそのお客様から受け取った。
お客様「計算ソフトは、オンプレ側とクラウド側の両方で稼働している。オンプレ側では時間があまりにかかるという事象はなく、クラウド側ではその事象が頻発している」と。
そして「やはり、外れデバイスがあるのではないのですか？」という一文で締めくくられていた。
送付された、再度アップデートされ、証拠たるオンプレミスとクラウドでの計算時間が書かれた表をダメ押し的に読んだ。
本音を言えば「では、クラウド使用をやめてオンプレミス側で計算してください」と頭の中をよぎった。
しかし、それを言ったら最後、このクラウドの内側で仕事ができなくなってしまう。
クラウドサービスを提供し、その手数料としてお金を頂き、そのお金を最終的には給与として受け取っている現実を直視するという原始的な態度で、本事象を見つめなおしてみた。
ここまでくると日本人リクエストは細かさではない。
まっとうなリクエストをされてきていると。
もっと真摯に本事象を解消すべく、このリクエストを処理しなければならないと。
個人的な立ち位置でいえば、このリクエストを最終的にクローズに持っていき、筆者も弊社もお客様も、関わっているもの全てが win-winになってくれることで、クラウド系ITエンジニアとしてサバイバルをしていく自信と覚悟を確固たるものにしたいと。

基本に立ち返り調査をしてみた
クラウドで計算しているというホスト側のモニタリングのグラフを読み込んだ。
計算中、CPUは張り付いていたが問題なし。
次にメモリー、ハードディスクの実装が妥当か否かを調査した。
こちらも問題なし、妥当だ。
そして次に、ログを調査した。
その際は祈りも願いといった気持ちはない。
逆に、なんとしても、手がかりだけでも見つけてやろうという意気込みでログ調査を開始している自分がいた。
何千、何万という出力されたログがそこにはあり、フィルターを駆使して不要な出力ログを消去していった。
残ったログを読むと、一つの共通項を見つけた。
あまりにも時間がかかる計算がされている際、ある警告が頻繁に出ていた。
その警告は公式ドキュメントにも記載されてはいるが、本事象のように処理速度影響の記載はない。
ただあるのは、その警告がでた理由と解消方法だけが記載されている。
共通項として、あまりにも時間がかかる計算がされている際に出力された警告が現実として存在するのであれば、たとえそれが原因の可能性が低くとも、切り分けをしていくことが必要となる。
その態度に自信をもって、お客様へ送信した。
「…といった共通項が調査したログから見つけました。問題切り分けのため、その警告を直す作業をご参照の上、警告解消作業を実施してください。その作業後に恐れ入りますが計算ソフトを実行されて、本事象の再現がされるかどうかの実施とその結果共有をお願いします」と。

何回かのやりとりのあと、結果としてその警告発生が本事象の問題であったことがわかった。
警告解消作業後は通常とおり、計算ソフトの実行は時間内で終わっている。
正直、こういうことがあるのだなというのが感想だった。
そのお客様が名残惜しそうに一カ月ほど続いた本件リクエストの終了を押してくださる内容のメッセージを受け取った中で、びっくりしたことがあった。
それは、そのお客様がとある公式発表会で、本事象について発表をし、かつ、自分が行った作業とその解決方法を発表すると。
その公式発表会にはマスメディアも参加されるとも書いていたため、あらためて自分の行った技術的作業はもちろん、社会人としての態度に問題はなかったかと恐る恐る振り返ってはみたが、時は既に遅く、そのリクエストはクローズされていた。
そして、対応評価満点がつけられていた。
これでクラウドエンジニアとしてサバイバルしていこう、という気持ちになった。

クラウドの内側では人間臭いことが多々生じる。
その人間臭さを上手に操ることもまた必要とされているのだと理解してくれたら、このコラムを書いているものとして、そんなに嬉しいことはない。

2022年9月吉日