インフラエンジニアって何してんの？

「ラクス Advent Calendar 2022」
12月23日（金）担当のインフラエンジニアです。今回は知られざるインフラエンジニアの仕事について触れてみたいと思います。

はじめに

最近（でもないけど）twitterなどで駆け出しエンジニア？の方のツイートをよく目にするようになりました。

「駆け出しエンジニア」というと文字面からは1年目のなりたてエンジニアのような印象を受けますが、どちらかというとこれからエンジニアを目指すために勉強をしている方を指すことが多いようです。

そういった方のツイートを見ていると9割以上はプログラミングの話。実際に業界内で働いてみれば要件定義など単純にプログラミングしていればいいだけの世界ではないことは重々承知かと思いますが、未経験の方にはエンジニア＝プログラミング、エンジニア＝開発、というイメージがやはり強いのでしょう。はたまたインフラエンジニアなんて世界については知る由もないのかもしれません。

あとは1割未満の数少ないインフラに興味を持ってる方の「インフラってどんな仕事してるんですか？」という質問に対しての回答であまりにも多いのが「運用をしています」系の回答。これについては（私の勝手な体感ですが）何なら自分でインフラエンジニアを名乗っている方でもインフラ≒運用だと思っている方が一定数いらっしゃるように思います。いや、まあ間違いではないのですが、別に毎日監視してアラートチェックしてログ見て偶にバージョンアップ作業して障害対応して、、サーバとかスイッチいじって、、みたいなことだけをしてるわけではないです。（まあtwitterの文字制限の言葉のあやもあるでしょうけども）

ということで、インフラエンジニアって何してんの？ってのがあんまり知られていない気がしなくもないので、ちょっと語ってみようかと。もちろん私の見解が答えのすべてでもないので、まあインフラエンジニアの一部の仕事だと思っていただければ幸いです。

常にコストと戦っている

インフラとコストは切っても切れない関係があります。
新しいモダンな技術の話をしても想像がしにくいと思いますので、ありふれた技術を使った簡単なシナリオ例を用いて説明します。

あなたは中途でインフラエンジニアとしてA社に入社しました。そこでは物理サーバを100台運用しているとします。
社内報曰く「サービスの売れ行きは好調だ！今後5年で売上XX万円伸ばしたい！」と社長は昨年の成績にご満悦のようです。

ここでインフラエンジニアが考えることの一つとして、今後サーバの増設頻度も高くなっていのでは？ということ。
その場合物理サーバをもっとたくさん買って200台300台としていく、、というレガシーな方法もありますが、いちいちデータセンターに行って物理サーバ1台1台OS入れて構築するのも無理が出てくるでしょうし、インフラ部隊の人員数的に将来詰むのでは？と考えたあなたは、仮想化して集約してみたらどうか？という提案をするとします。
しかしここで問題になってくるのがコストの話です。

極端ですが、サーバ1台20万円とした場合、100台で2000万円。100VMを集約する巨大なサーバ＋ライセンスを買うのに5000万円かかるとします。
そうなると、これってコスト的には損してますよね？会社がそれを許容することはないでしょう。
そうとう金持ちか、モダナイズに力を入れている企業であればコンテナなどの話を持ち込めば興味を持ってもらえるかもしれませんが日本ではそう多くないでしょう。

まあ、サーバって単純にサーバ購入費用だけがかかるのではなく、
・工事費用、ケーブル類などの初期費や雑費
・ラックの月額費用
・配線やマウントを外部に依頼する場合作業費
なども当然含まれまして、これを仮に6年償却などで考えるとラック月額費用が超絶でかい破壊力を持ってたりするので、
物理サーバ台数を減らしてラック数が減る事よるコスト効果というのは計り知れないものがあるわけですが、
そういった数年レベルのコスト計算をしたうえで提案書を書きステークホルダーを納得させなければいけません。

それでも物理サーバの安さを追い越すことができず「運用コストがXX削減になり・・」といった魔法の係数とグラフを駆使して上層部と戦うケースなんてのも世の中にはザラにあるわけですが、
「業務効率化できるところがもっとあるのでは？」「自動化もっとできるでしょ？」などと上層部に切り返されて自信をもって「やれることはやり切ってます！」と回答できる方は極少数でしょう。

そうそう簡単にサーバ増やすとか新しい機器入れるとかクラウドにもっていくとか出来る訳ではないということです。
そして最後にとどめを刺される一言を言われます。
「そもそも予算はとってないよね？」
当たり前ですが唐突に買いたいと思っても好きな時に買える訳がありません。
インフラエンジニアの仕事は予算取りから始まっています。

こういったコストとの戦いはインフラエンジニアの仕事では日常のテーマです。

（※）補足：5000万って盛りすぎじゃね？と思ったかもしれませんが、具体的に世の中のサーバがどれくらいの値段なのか？については数多の政治的要因が絡むため申し訳ないですが公表は出来ません。上記はあくまで極端な例ですが、仮想化して集約したりクラウド化したら安くなるというのは簡単には言えないということだけは事実です。

プロジェクトの管理をする

さて、なんやかんやありましたが、仮に仮想化案件にOKが出たとして話を進めましょう。
部長に「いい提案だな。役員からOKでたよ。じゃあ明日から君が主導で導入進めてくれ。頑張れよ。」とお言葉をいただきました。
さて、どうしましょうか。

よし、技術的な設計しよう！と思ったあなた。設計も同時並行で必要ですがそれ以上にプロジェクトとして準備することが山ほどあります。
・スケジュールの作成
・人のアサイン
・関係者との合意/キックオフ
・購入ベンダーとの調整　ご挨拶～NDA締結～法務処理～コスト交渉～納期調整など山盛り
・稟議や購買関係、発注処理などの社内対応

適当にリストアップしましたがまだまだ沢山あるでしょう。はっきり言ってサーバを発注するまでに息が切れそうですw
プロジェクトという括りで言うと最初の予算の話やコスト計算、提案の段階から既にプロジェクトの一部ではありますが、
機器の導入というのは単独ではなくチームで進める規模になる事も多く、そこには数多のタスクが発生します。
特に昨今の業界動向なども考慮しつつ機器納期やファシリティ工事周りを踏まえたバッファ込みのいい感じのスケジュールを作るのには、経験とある種のセンスが必要になり簡単そうでいて想像力を相当使うことになります。

早くサーバを触りたいのに！それをやりたくてインフラエンジニアになったのに、と思うでしょうが、
プロジェクトのマネジメントが出来なければ導入は出来ませんし、
技術の前にコミュニケーションスキルというのが非常に重要になってきます。

全体を考慮した設計をする

ようやく技術の話ですが、サーバを発注した後にすることはいわゆる詳細の設計であり、
大枠の基本設計というのは最初の提案の段階でしてたりしますので、話は一部前後しますことをご了承ください。

仮想化においてサーバのリソースについては皆さん当たり前ですが検討するでしょう。
1OSあたり4vCPU、メモリが8GB必要なのであれば、100台乗せるには400vCPU、800GB必要なのか、そのサイズのサーバを買うか、、
などという話は簡単にできますが、インフラエンジニアであれば開発チームなどが考慮しにくい設備全体を総合的に考えるべきでしょう。
（もちろんオーバーコミットを考慮する場合は全然話は違ってきますが）

まあまず性能は開発もインフラもみんなシビアに考慮するでしょう。
集約したらそもそもI/O性能は足りるのだろうか？なんてのは当然考慮が必要です。
インフラエンジニアはIOPS/レイテンシ/スループットなどもKPIを出して計測出来るのが理想です。
100台集約してクソほど遅くなりました、では顧客はみんなサービス解約しちゃいます。

そして、ディスクなどパーツが壊れたらどうなる？、物理サーバ自体が丸ごとタヒんだらどうなる？
などの可用性、耐障害性などの側面はまあ当然として、
細かいところを取りこぼしがちですが（^^:）100VMをそもそもどうやって管理する？バックアップは？監視は？といった非機能/運用面などもまあ検討するでしょう。
あとは物理サーバからの移行が前提なのであれば、そもそも物理から仮想へ移行どうやってやるの？という話もありますね。

この辺までは開発の方も想像つくと思いますが、インフラエンジニアであればもう一歩俯瞰してみてください。

集約したら当然ネットワークの帯域については超絶重要な考慮ポイントになります。
既存のネットワークでそもそも集約に耐えられるでしょうか？
あとはデータセンターレベルまで考慮を広げてみましょう。
・帯域はWANの回線まで考慮していますか？IP数は考慮していますか？今後の増設に耐えられますか？
・ラックの電源は何ボルト、何アンペアでしょうか？耐荷重は？でかいサーバそもそも載りますか？
・配線の種類、距離などは考慮していますか？
他にも多々あるでしょう。

コンテナ、k8s、みたいなキラキラした話が空中を飛び交う昨今、インフラエンジニアは地を這い泥臭いところまで常に考えておきたいものです。

あと片づけをする

さて、山あり谷あり苦労はしましたが、無事に物理サーバ100台を仮想化できたとしましょう。
喜ぶのはまだ早いです。余った物理サーバ100台ってどうするつもりですか？

再利用する計画があるなら使えば？再利用しないとしたら捨てればよくね？と思うでしょうがそう簡単な話ではありません。これも立派な固定資産で税金も絡んできます。
ここはちょっと独特で私も経理に詳しいわけではないので大した説明ができなく恐縮ですが、
減価償却資産には耐用年数というものがあり、仮に6年で計算すると、
50万円で購入したサーバ3年つかって除却するとしたら、経理上は残り3年ホントは使えるのに25万円分損してるってことになります。
これって単純ではなくてその年度の利益が減ることになります。（場合によっては会社の信用にも関わります）

もちろんこう言った話は事前の提案の段階で話されていたりするものですが、
新しいサーバを買う、古いサーバを捨てる、というのは結構ややこしいことなのです。

じゃあ置いておけば？と言っても、ゴミに空調完備の高いラック賃貸に住まわせておくの？と考えると切ない事なのが分かりますね。
じゃあサーバをラックから降ろせば？そしたらどこに置いておくのでしょうか。そもそもサーバは加重的に何台も縦積みできません。

運用をする

ようやくここまで来ました。多くの方がご想像のインフラエンジニアの仕事？
にようやく到達ですが、ここに至るまでに実は長い長い過程が存在する、というお話でした。

さいごに

実は今回の話の前段に「情報収集」というものが含まれまして、そもそも情報や知識を知らないとサーバ増えそうだから仮想化しようみたいな発想にも至らないわけで、アンテナを張ること自体からインフラの仕事は始まっています（まあこれはインフラに限らずITエンジニア全般に言えますがね）

ああ、インフラエンジニアって大変そうだな。。と思った方もいらっしゃるでしょうが、逆にこう思った方もいるかもしれない。
「全部AWSでよくね？」ってね。
（毎年恒例のAWSオチ・・）