２０２１年のある日
オンプレミスをメインで活動していたインフラエンジニアが過労で倒れた。
どのくらい時間が経ったのか。。。目覚めたらユニファのクラウドエンジニアになっていました。。。（違う！！！）
。
。
。
始めまして、
ユニファのプロダクトエンジニアリング部でインフラを担当しているカンと申します。
昨年10月に合流して今回が初めてのtech blog参加なので自分が経験したオンプレ環境とクラウド環境の差と新しい環境に慣れるまで考えたことについて話をしてみたいと思います。
AWSとの出会い
クラウドサービスを使ってシステムを構築したのは２０１５年が初めてでした。
当時の仕事はオンプレの物理サーバを仮想化してプライベートクラウドシステムを構築してそこの会社のプロジェクトのサーバを構築と運用することでした。
が、会社がつぶれてしま。。。
とにかく色々大人の事情で他の会社にプロジェクトを移管する必要があったのでAWS上にシステムを作ることになりました。
当時にはAWSクラウドのサービス数も少なかったしクラウドってオンプレを仮想化しただけだと思いました。
実際にオンプレインフラのアーキテクチャをそのままAWS上に再現する形で構築しました。
今考えてたら恥ずかしいのですが、クラウド？別に大したことないな。とか 物理作業がないからちょっと早くて分かりやすく構築できるくらいが感想でした。
オンプレとのお別れ
AWSと出会ったけどオンプレの構築と運用、最適化との戦いは６年くらい続けていてもう世の中のトレンドとはどんどん離れていくのではないかと感じました。
私は最近のトレンドを確認する為、転職サイトの内容を月１回は確認しようとしています。そこから最近会社から求めるスキルや人材像を分かることができるからです。
何年か前からDevOps、SREなどクラウド環境のエンジニアを探す会社が多かったので、もっと遅くなる前にもうそろそろオンプレと別れないとダメかなぁと考えました。
考えたらすぐ行動にするのが得意なので、以前から行って見たいと思った会社、クラウドの世界が広がっているユニファに合流することになりました。
クラウドインフラとの出会い
クラウドは以前経験したことあるし結局オンプレを仮想化しただけだと思っていたのに実際は全然違いました。
このポスティングの頭に軽いジョークで話したように異世界に転生したような感じでした。
なぜならオンプレのインフラとだいぶ違かったからです。
それだけではなくAWSを初めて使った時より何倍もメニューと機能が増えていてもっとびっくりしました。
それに論理的には同じ作業だけどオンプレと違う方式で行うので新しく勉強することを多かったです。
その中で一番インパクトを大きく感じたのはIaC（Infrastructure as Code）でした。
ユニファはterraformを使ってインフラ構築を自動化していて、これは自分にとってAWSだけではなくterraformの勉強も必要ってことでした。（笑）
terraformはインフラの完成した構成をコードで表現してこれを適用すると宣言通りのインフラリソースがクラウド上に作られます。
これはオンプレ環境をshell scriptで自動化して来た自分にとってはとっても嬉しくて幸せでした。
そしてIaC環境ではチーム内部のコミュニケーションにも役に立つことを分かりました。
以前には絵で構成を描きながら話した方が早く伝えましたが、その絵の代わりにコードで話せるので作業のレビューがコードで管理してなかった以前より具体的で分かりやすくなりました。
オンプレとクラウドの違い
何より大きい変化を感じたのは普段やって来た作業が簡単になったのが一番大きい感想でした。
具体的な事例でDBのバージョンとスペックアップグレードを例えてみます。
実際の作業では他チームや部との色んな調整とか事前調査、作業計画の作成など複雑な仕事がもっと入りますが、ここではサーバ関連作業に限って作成しました。
比較的に複雑で大きい規模のデータベースのバージョンとスペックアップグレードがこんな簡単に終わって大丈夫か？と心配をするくらい作業が簡単になることが見えます。
このように時間のセーブができるのでエンジニアは自分のリソースを他の仕事に集中できるし、これはサービスの安全性、信頼性に繋がります。
複雑で難しい作業を早くて安定的に処理できるから作られる余裕は会社、エンジニア、サービスを使うユーザ、皆さん全部に美しい話だと思います。
オンプレもクラウドも変わらない仕事
違うところが先に見えたのですが、変わらない部分もありました。
一つ目はインフラの設計です。
ここで何かを設計して構築したことはまだないですが、このインフラ設計はオンプレもクラウドも必要です。
各環境ごとに最適化の方法も使うツールも違うところがあるのでその辺は差がありますが、サービスを支えるインフラを設計する点では同じです。
二つ目はモニタリングです。
アプリのログやサーバのステータスを収集してインフラが元気なのか見守ること。そして問題が発生する前にその原因になるものを事前に対応するのはインフラの基本であり変わらない部分です。
伝統的に MRTG, Cacti, ZabbixなどからCloudWatch, Datadog, Prometheusなどにツールに代わりますが、サーバのリソースを確認する機能は同じです。
最近のモニタリングツールはAPIを使えるし自動化ツールと連携して色んな機能の応用ができるので、もっと安定的なインフラ運用に必須になりました。
三つ目は性能の最適化です。
どんなインフラ環境でもサーバが最適な性能を出せるようにするのはとっても大事です。
場合によって違いますが、実際にデフォルト設定だったら４台のサーバで処理したのがカーネルとアプリケーションのチューニングで１台で処理できることを経験しました。
オンプレもクラウドも使うサーバリソースとプログラムによって色んなチューニングができるしこれで得られる効果は大きいので最適化も変わらない業務だと思います。
四つ目に自動化システムの構築です。
オンプレでは複雑で難しい開発が必要な作業でしたが、クラウド環境では以前より制約がなくなって領域がもっと広くなったと思います。
特にAWSのLambdaは既存には想像もできなかった作業を可能にしてくれます。
例えば、次のような流れでの作業ができます。
ある開発コードをビルドしてそのファイルをS3にアップロードする
LambdaはS3の更新を検知
どんなファイルが更新されたかを確認
どこのサーバにデプロイするか判断
サーバデプロイ
このようなパイプラインを作っておくと開発側からは開発後ビルドをしてS3にアップロードすればサーバの構築と新しいリソースのデプロイまで自動完了することができます。
DevOps、SRE、Infra Engineer
最初はUnixをメインで使うエンジニアでしたがLinuxに乗り換えました。その時、あまり難しくなかった記憶があります。もちろん勉強はずっと続けてたので知識のアップデートはずっとありました。
同じくオンプレを長い期間使ってたのでそれを仮想化しただけのクラウドはすぐできると思いましたが全然違いました。
転生
転職してから８ヶ月目ですが、まだまだだと思います。
このポスティングを準備しながら考えてみると違うところだけではなく変わらないところも多いことを改めて気づきました。
環境（オンプレ、クラウド）や職名（インフラエンジニア、DevOps、SRE）とは関係なくサービスのインフラを担当するエンジニアに一番大事にことはサーバに興味を持っていつも見守ってサーバが痛い時あるいは痛くなる前に直してくれる力が必要ではないかと思います。
サーバの親、サーバの医者見たいな人が私たちのアイデンティティではないかと考えました。
もしオンプレからクラウド環境への転換を難しく考えるエンジニアがいらっしゃったら結局インフラはインフラのお仕事をすればいいのでご心配なく挑戦してみてください！という話を伝えたいです。
このポスティングがインフラの運用環境で悩みを持っている方々に役に立つことを願います。
ユニファで一緒に働く仲間を募集しています！
