コラム

はじめに

こんにちは。BTCクラウドCoEインフラ担当の池浦です。

今回のブログのテーマは前回に引き続きクラウド移行ですが、クラウド移行のテクニカルは話ではありません。ちょっと趣向を変えまして、オンプレからクラウドに移行(?)したインフラエンジニアの現状を個人的な経験をもとに書いてみたいと思います。

いまさら感の強い内容ですが、これからクラウドをやってみたいと考えているインフラエンジニアの方の参考になると幸いです。

クラウド前

業務でクラウドに本格的にかかわるようになり約2年になります。まだまだベテランには程遠い未熟者ですが、インフラエンジニアとしては15年くらいの経験があります。クラウドに触れる前は以下のようなスキルセットでした。ここ7~8年くらい、つまりキャリアの半分くらいはインフラエンジニアではありますが、アプリチームの中のインフラ担当というようなポジションで仕事をしていました。

• ネットワーク・ストレージ・仮想化
  一通り運用や構築は経験しましたが、専門的にやっていたわけではありません。Webアプリケーションのインフラを中心にやっていたので、ネットワークに関してはL7の設計・構築は比較的得意な方でした。ストレージや仮想サーバなどは提供側ではなく、利用者側としての関りのほうがメインでした。
• OS・ミドルウェア
  10年くらい前まではWindowsメイン、その後はほぼUnixとLinuxで、ここ5年くらいはLinuxばかりになりUnixも触ることはなくなっていました。ミドルウェアもクラスタソフト、バックアップ、監視、アンチウィルスなどのいわゆるインフラ系のミドルウェアを触ることはあまりなく、Webサーバ、アプリケーションサーバ、NoSQL系、RDBなど、アプリケーションと直接かかわるミドルを専らいじっていた感じです。
• その他
  シェルスクリプトはよく書いていましたが、アプリケーション開発の経験はありません。セキュリティについても専門でやっていたことはないので人並程度の知識でした。ネットワーク周りのセキュリティとか、ウィルス対策とか、そのあたりです。

クラウド後

続いて、クラウドをやるようになって、自分が必要とするスキル、あるいはチームから求められるスキルがどのように変化したのかを書いてみたいと思います。

• ネットワーク・ストレージ・仮想化
  このレイヤはクラウドにより最も恩恵を受けられる部分だと感じます。言い換えれば高度な設計・構築のスキルが必要ではなくなってきたものだと言えます。もともとそれほど関わってはいなかったレイヤですが、これらの中でネットワークについてはクラウドにおいても改めて非常に重要なスキルであると感じています。オンプレとクラウドを繋ぐハイブリッドクラウド環境を構築する要件は多く、IPsec-VPNやBGPなどは、機器のコマンドレベルの知識も必要とされることもあります。正直、ルータの設定を自分でやる日が再び来るとは思ってもいませんでした。
• OS・ミドルウェア
  代表的なパブリッククラウド上ではいわゆる商用Unixは動かすことができないので、クラウド上でUnixを触る機会はほとんどないといってもいいかもしれません。
  一方で、LinuxやWindowsはというと、現状ではまだ使う機会はそれなりにあるかな、という印象です。しかし、これらもサーバOSとして使うことは今後減っていくと思われます。マネージドサービスやコンテナ、サーバレスアーキテクチャが主流になっていくと考えられるからです。ミドルウェアは相変わらず扱うことは多いですが、OSにインストールして、パラメータ設計して、冗長構成を実現して、等々というような関わり方は少なくなりました。RDBやKVS、全文検索エンジンなどは、可用性も備えたマネージドサービスが提供されています。Webの複雑なトラフィック制御をするような場合は、NginxやApacheなどの専用のミドルウェアが必要になることもありますが、多くの場合はクラウドが提供しているロードバランサやCDNのサービスでカバーできてしまいます。また、監視についてはクラウドの監視サービスや、DatadogやMackerelのような外部のSaaSを使うことが多くなってきており、監視サーバを構築するようなことはやらなくなっています。
• その他
  運用ツールとしてシェルスクリプトを書く機会も減ってきました。かわりにPythonで自動化ツールを作るようになりました。正直なところまだまだ見様見真似でやっているので、ちゃんと勉強しないといけないと感じているところです。他には認証系の技術も関わるようになりした。OpenID Connect、SAML、OAuth、あるいはActive Directoryなどですね。この辺りはまた別の機会にブログにしてみたいと思います。
  

  Infrastructure as Code

  少し話は変わりますが、現在のシステムインフラに関する重要なキーワードとして、「Infrastructure as Code」（以下、IaC）があります。これ自体はオンプレの時代からあったものであり、Ansible, Chef, Puppetなどを使っていたインフラエンジニアの方は多いのではないでしょうか。Ansible等は主にOSの中身を設定・管理をすることが多かったかと思います。クラウドにおけるIaCの役割はOSの外側、つまりネットワークや仮想マシン本体、マネージドのRDB等を設定・管理する方向に変化をしてきていると感じています。それに伴いツールも、Terraform, CloudFormation(AWS), Azure Resource Manager(Azure)などが主役になりつつあるのではないでしょうか。

   

  Immutable Infrastructure

  もう一つ重要なキーワードとしてあげられるのが「Immutable Infrastructure」です。これもオンプレ時代からあった考え方ですが、IaCと比べると少しマイナーな言葉かもしれません。簡単に説明しておきますと、「不変(Immutable)なインフラ」という意味でして、一度構築したインフラに手を加えないという考え方です。Immutable Infrastructureでは、既存のOSやミドルウェアの設定変更、パッチ適用などはおこなわず、そのような必要がある場合には一度インフラを破棄して、再構築するというアプローチをとります。こうすることで手元にあるコード（IaC）と乖離がない環境が保たれることになり、サーバの状態を管理することが不要になります。インフラエンジニアにはお馴染みのシステムバックアップを取る必要もなくなります。標準構成の仮想マシンを新規作成し、AnsibleやChefでミドルウェアをインストール、設定するというのがオンプレ時代のよくあるパターンでした。

  最近のImmutable Infrastructureといえば主役は何といってもコンテナです。もちろんオンプレでもコンテナは動きますが、Immutableにするにはコンテナ側とホスト側の両方で対応が必要となります。クラウドではホストOSはマネージドなので構成を意識する必要はありません。クラウドとコンテナが組み合わさることで、漸くImmutable Infrastructureが真価を発揮しはじめたといえるのではないでしょうか。

   

  おわりに、そしてDevOpsへ

  今回、クラウドの前後で自分のスキルの変化を振り返ってみたわけですが、私の場合、クラウド特有の知識を習得したり、担当するインフラのレイヤが広がったということはありますが、全体としてそれほど大きな変化はないな、というのが率直な感覚です。これはインフラエンジニアとしては比較的アプリケーションに近い位置で仕事をしていたことが大きいと思います。

  ただ、それでも一つだけ大きく変わったと感じていることがあります。それは、「作りこむ」ことが減ってきたことです。オンプレ時代はカーネルやミドルウェアをガリガリとチューニングしたり、シェルスクリプトで何でもかんでも作っていましたが、そのようなやり方は、IaCやImmutable Infrastructureとあまり相性が良くないと感じています。できるだけ作らずに、有りモノのサービスを使い、それらを「組み合わせる」のがクラウド的なインフラなのかな、と思うようになりました。このようにいってしまうと誰にでもできる簡単なお仕事に聞こえてしまいますが、クラウドはサービスのアップデートのスピードが尋常ではなく、それらをキャッチアップしていくだけでもかなり大変なのが実状です。今後も苦労が絶えることはなさそうです。

  最後に。昨今クラウドによるビジネスの加速が様々なシーンで語られていますが、その多くがDevOpsの重要性について言及しています。そんな中、設計や構築フェーズを担当しているインフラエンジニアの中には、開発者(Dev)でも、運用者(Ops)でもない自分はDevOpsとは無縁だと思っている方もいるかもしれません。しかし、IaCやImmutable InfrastructureはDevOpsを支える重要な技術要素であり、その名のとおり本来的にはインフラエンジニアの領域といえます。クラウド時代において、とかく存在意義が問われがちなインフラエンジニアですが、自分の役割を認識し、プレゼンスを示していきたいところですね！

  それでは、また。