本記事は基盤デザインウィーク 2日目の記事です。
🌈 1日目 ▶▶ 本記事 ▶▶ 3日目 💻

気付けば入社して14年。2010年入社の小林です。

いつの間にか基盤デザイン事業部では部長に続き2番目の古株となっていました。
もう今の若手（〜5年目ぐらい）はサーバというものを触ったこともない人もいるような時代になっています。

今回は基盤デザイン事業部ウィーク（長いので基デザウィークと呼んでいます）ということで、入社2年目にインフラチームに配属された当初のオンプレミスシステムばかりの時代を懐かしみつつ、情報システムにおけるインフラの今と昔の違いについて考えていきたいと思います。

オンプレミスの時代

仮想化前

さて、読者の皆様はサーバを触ったことはありますでしょうか？

「メインフレームからやってるぞー」という声も聞こえましたが、私はメインフレームは経験ないので少し置いておきます。

私がインフラチームに配属されたころはデータセンターにサーバを設置し、それを使ってシステムを構築することが普通でした。
AWSは2004年からあったらしいのですが、当時そんなものは全く知りませんでした。

当時のクラウドサービスというと、メールサービス（私はHotmailを使ってました）やストレージサービス（Dropboxよく使ってました）といったSaaSが主流で、クラウド上のサーバを使ってシステムを構築するなんてことを考えたこともありませんでした。

データセンターにはこんな感じでサーバ機器がいーっぱい並んでました。

サーバ機器を買って（1台数十万〜100万ぐらい）、データセンターに設置して、電源ケーブルやLANケーブルを配線して、OSをインストールして、ミドルウェアをインストールして、開発したアプリケーションをデプロイして動かす。
これが当時の情報システムの形でした。
なお、仮想化が普及する前はサーバ機器1台が1つのサーバの役割を果たしていたので、冗長化する場合、例えばWebサーバを4台構成にするならサーバ機器は4台買う必要がありました。

仮想化の登場

Webサーバを4台構成にするならサーバ機器は4台買う必要がありました。

当時はIaC（Infrastructure as Code）はまだ普及しておらず、サーバの構築というと構築手順書や設定一覧（パラメータシート）を作ってそれに沿って1台1台インフラエンジニアが手作業で設定していました。4台冗長構成なら同じ設定作業を4台のサーバに同じように行います。
（こう書くと伝統工芸品みたいですね）

仮想化が登場するとその手間は一気に減りました。
最初の1台のサーバは手作業で設定する必要がありますが、サーバをソフトウェアとして扱う仮想化技術を使えば同じ設定のサーバを簡単に複製することができるようになり、「冗長化のために4回行っていた構築作業が1回で済む」といった大幅な効率化ができるようになります。

その後IaCも普及し始め、手作業だったサーバ構築もコマンド一つで行えるようになり、インフラエンジニアの手作業はどんどん少なくなっていきます。まさに産業革命ですね。

オンプレミス時代の運用

さてさて、だんだん手作業が減っていくインフラエンジニアのお仕事ですが、どうしても人の手でやらないといけないことが残ります。
そう。サーバ機器のお世話です。

導入準備
- 機器をデータセンターに設置する。
- 機器に電源ケーブルを繋ぐ。
- LANケーブルを繋ぎ、ネットワークに接続できるようにする。
- 起動、停止、冗長化しているケーブルの動作を確認する。
日々の運用
- サーバが故障してないかランプの状態を確認する。
- ハードディスクなどの故障の際に部品を交換する。

設定作業などは自動化、簡略化ができても、こういった物理的な作業はインフラエンジニアの負荷の高いお仕事として残っていきます。

私はインフラチームに入って2年目にデータセンターの電源系統老朽化対応（10年に1度ぐらいの頻度で実施するらしい）に当たってしまい、お客さんがシステムを利用しない年末年始の夜間に全サーバの電源ケーブルを新しいコンセントに差し替えるというお仕事（専門用語で電源盛替えというらしいです）をした経験もあります。

クラウドの登場

電源盛替えをやりとげた翌年頃から私はAWSの案件に参画するようになります。

IaaS（Infrastructure as a Service）の衝撃

当時携わっていたAWSを用いたシステム基盤は、EC2でWebサーバを、RDSでDBサーバを構築し、ELBでアクセスを振り分けるというシンプルな構成でした。当時はLambdaさえまだ登場していなかったと思います。

遠目に見ると、IaaSであるEC2をこれまで自前で用意していたサーバと置き換えただけの「自分たちでオンプレミスで設置していたサーバ機器を誰か別の人が用意してくれるようになった」というぐらいの違いでしたが、前述のとおりインフラエンジニアとしての大きな負荷であった物理機器の運用をどこかの誰かがやってくれることはとても大きな革命でした。

PaaS（Platform as a Service）による業務内容の変化

さらにクラウドは進化します。先程出てきたRDSのようなPaaSの種類が増え、機能も充実していきます。
AWSで言うと、RDS、S3、Lambda、ElastiCache、ECS…
インフラエンジニアは「仮想サーバ（EC2）に機能を追加して、DBサーバ、ファイルサーバ、バッチサーバ、キャッシュサーバといった役割を持たせる」のではなく、「より最適なサービスを選定し、うまく組み合わせることでシステムとして動くようにする」という役割を担うようになっていきます。

クラウド時代の運用

クラウドを利用するメリットとしてしばしば挙がる項目に「サーバの管理をしなくてよい」というものがあります。
今はクラウドに構築されたシステムを運用する身になりましたが、「このサーバ、5年たったからそろそろ買い替えかぁ」とか「最近ネットワークエラーがよく出るからLANケーブル交換しとくかぁ」といった物理的なメンテナンスを気にすることは全く無くなりました。

ではインフラエンジニアのお仕事は初期設定やリリース後にシステムで出たエラーの対処だけでよくなったの？と思われるかもしれません。
もちろん答えはNoです。

クラウドは日々進化しています。昨日までプログラムの作り込みで実現していた機能が新しいサービスとして提供されるかもしれません。
また従量課金制なので、システムの動作状況から利用しなくてもよい機能が見つかれば、使わないように変更することで費用を抑えることができるかもしれません。

「システムの特性と利用状況を把握し、進化し続けるクラウドとの整合性を高める」ということがクラウドを利用するシステムを担当するインフラエンジニアの役割になると考えています。

クラウドエンジニアとは

最近は「クラウドエンジニア」という呼び名も見かけるようになりました。

インフラエンジニアとの違いは何か？と問われても明確な答えは無いと思いますが、本記事で書いたようにクラウドをシステムに活かすにはクラウドサービスへの知見を深めることだけでなく、担当するシステムの特性をよく知り、どのクラウドサービスを適用することがベストなのか？を判断できることが非常に重要なスキルとなります。

クラウドサービスを利用する際、基本的にベストプラクティスは「作りこまないこと」と言われます。
例を挙げるとこういったものがあります。

ファイルを保管するにはEC2でファイルサーバを構築するより、S3やEFSなどのストレージサービスを使いましょう。
データベースはEC2にRDBMSをインストールするのではなくRDSを使いましょう
バッチサーバを用意しなくてもLambdaを利用する方が良いでしょう

さて、果たしてこれはすべて正しいでしょうか？
担当するシステムの特性を考慮するとこれらのサービスはベストなのか？という観点でこういったことを考える必要があるでしょう。

S3やEFSで性能要件は満たせますか？
RDSで設定できない特殊な設定は必要とされていませんか？
バッチ稼働時間などを考慮して、Lambdaのタイムアウト上限は十分ですか。コスト面はどちらが上ですか？

クラウドに特化したクラウドエンジニアとは何か？と考えると、こういったクラウドに特化した知見を持ち、最大限に活かすことができる人という答えになるかもしれません。
もう少しやわらかく言うと、「クラウドサービスにすごく詳しくて、一番いい使い方を提案できる人」と言い換えるとしっくりくるような感じもしますね。

以上、若手時代を「むかし」と呼ぶことに若干の抵抗を覚えながら書き進めた小林がお送りしました。