クラウド専業インフラエンジニアの今(登壇こぼれ話)

先週末にこんなイベントに登壇しました。

今までとこれからのITインフラ /iret tech labo #1 (2020/07/17 17:30〜)

自社で初回ということもあり、企画段階から参加させてもらいましたが、Live配信でコンテンツを届ける大変さをまざまざと感じました。
運営のみなさん、本当にお疲れ様でした。

アーカイブ動画も公開されているので、ぜひご覧ください。

私は インフラエンジニアは消滅するのか というタイトルで登壇しました。

ちょっとタイトルで煽りすぎましたかね？ｗ
元々、イベントタイトルになっている 今までとこれからのITインフラ も私が出した案でして、自分で自分のハードルを上げてしまった気がしてます。

インフラエンジニアは消滅するのか

最近よく聞く話かと思います。サーバーレス(FaaS/SaaS)の登場によって、サーバーを主戦場とするインフラエンジニアは無用になるんじゃないかという予想に基づくものですね。私の予想では、インフラエンジニアのお仕事はしばらくなくなりません。詳しくは資料やアーカイブ動画でご覧いただければと思います。

クラウド専業インフラエンジニアの今

登壇時は今までとこれからについて話しましたが、今どうなのかにはあまり触れなかったので、この記事で書いておこうと思います。

意外とIaaSが多い現状

クラウド専業というと、サーバーレスサービスを組み合わせてイケイケなシステム構築をしているイメージが強いかもしれません。もちろん、私達はそういったイケイケシステムを構築する技術を持っていますし、実際にそういったシステムのご要望いただくことも増えてきました。しかしながら、お客様からの注文はまだまだIaaS中心のシステム構成が多いです。

じゃあIaaSは古いからダメかと言うとそうではないです。IaaS/FaaS/SaaSも所詮は手段なので、乱暴に言えばアプリケーションが正常に動作すれば何を選択しても問題ないです。IaaSでもうまく組めばコンテナのようにコードで管理することも可能ですし。(コンテナでコード管理されていないなんてことも...モゴモゴ)

サーバーレス/コンテナは開発側が対応できない場合が多い

サーバーレスとかコンテナできる技術があるんなら提案すればいいじゃん！と思う方もいるかもしれませんが、実際はそこまで単純じゃなかったりします。これらのプラットフォームを使う場合は、サーバーを使うときにはなかった制限だったり、プラットフォームに合わせたコードの書き方を求められたりします。この部分に開発ベンダが対応できればよいのですが、経験的に難しい場合が多いです。さらに、運用(継続的デプロイ/アラートハンドリング/自動化手順が失敗したときの手動対応など)まで考えられるかとなると、ハードルはもっと上がります。特に運用は、この手の話をするときに抜け落ちやすいので、注意が必要です。

こういった事情があるため、
- このレベルの技術持っている開発ベンダと組む
- 弊社に開発も任せてもらえる
- お客様自身がこのレベルの技術持っている
という場合でないとIaaS注文に対してサーバーレス/コンテナの提案をするのは難しいのです。もちろん最初からサーバーレス/コンテナ前提の注文の場合は善処します。

こういったハードルを越えられる場合は、アーキテクティングと運用設計を中心にインフラが担当し、コード周り(FaaS自体の設計などを含む)を開発側が担当することが多いです。

運用という強み

システムの運用は従来からインフラ側が持つことが多いと思います。これは、アプリケーションが(エラーを吐くことを含めて)正しく動く前提で、NW機器/サーバ機器/OS/ミドルウェアなどに障害が起きたときに対応するためです(もちろんアプリ障害も)。なので、運用に関してはインフラに一日の長があることが多いでしょう。弊社でも基本的にインフラが運用を担当します。

先にも書きましたが、サーバーレスとかコンテナになっても運用はなくなりません。サーバやOSなどの面倒を見なくてもよくなっただけで、落ちるときは落ちます。なんらかの障害があったときに備えてフローを準備しておくことが重要です。

そんなもん自動化しとけばいいじゃん！という声が聞こえてきそうです。
たしかにその通りで、自動化して対応すれば運用の負荷をある程度軽減できます。障害復旧を自動化できる仕組みが機能として提供されることも増えてきました。しかしながら、自動化の仕組みもシステムなのです。故に自動復旧自体が失敗することは往々にして起こります。そんなときはリカバリー用の運用フローが必要になってくるわけですね。

リカバリー用の運用フローを作る上で何が重要かと言うと、自動化で何をやっているかがわかっていることです。システムがどうやって動いているかはもちろん重要ですが、自動化した手順の何がどう失敗したのかわからないとリカバリーのしようがないのです。なので、運用手順を先に書き、その上で自動化をしないと、実際の運用時に失敗してしまいます。

また、運用フローに人の動きを含めることも大事になってきます。最終的に自動復旧できなかった場合に手動で復旧することになるからです。この理由から、私は人も含めてシステムだと思っています。

こういった知識がインフラ側には溜まっているので、この知識を活かす場面は多いです。先日の発表でも触れたピタゴラスイッチのコンポーネントそのものや、そのつなぎ目で障害が起こった場合に、どのように復旧させるかをデザインする。ここに運用の強みが出てくるはずです。

まとめ

つらつらと書いてきましたが、現状は以下の2軸を中心にお仕事をしています。
- IaaSで今まで通りのサーバ構築+運用
- サーバーレス/コンテナのアーキテクティング+運用

プラットフォームが変わっても、アプリケーションが生み出す体験をエンドユーザに安定的に届けること、というインフラのミッションは変わらないと思っています。そのミッションを達成するため、今後はより開発を理解し、最適なピタゴラスイッチを設定/構築/運用する能力が求められるようになるでしょう。この変化に追従し、お客様へ最高の体験を届けられるように、今後も研鑽を続けたいと思います。