40代インフラエンジニアがようやくKubernetesを勉強した話

こんにちは。40代インフラエンジニアのAと申します。 今回は今さらながら、Kubernetesを勉強し始めたエンジニアのポエムになります。 あまり技術的な内容はありませんがご容赦ください。

経歴

私はエンジニア歴20年以上の世間では「ベテラン」といわれるインフラエンジニアで 経歴としてはSIerでOSインストールや機器設定を現場でがむしゃらにこなす所から始まり、 SaaS業界で運用を経て、昨今はオンプレ機器の導入・設計をリードする立場で働いてまいりました。 また、現在の会社は在籍年数も10年以上と長く、何やらベテラン臭のする、 「発言ばかりが目立つベテラン社員」に何となく居座っている状況でありました。

手作業のインフラの時代

少し時代をさかのぼりますが、20年前のインフラは手作業と物理作業が当たり前でした。 データセンターで徹夜のサーバチューニング、手動でのシステム再起動、 無駄に長いストレージのビルドを待ちながらの仮眠。 エンジニアのとてつもない長時間労働によって、システムの安定稼働が支えられていた時代です。 しかし、そんな私が長年培ってきた「手作業のインフラの時代」は、 多様な選択肢の中から最適なソリューションを設計することが求められる時代になっていました。 これまで自分が拠り所としてきた経験そのものが、時代遅れになってしまうのではないかという不安を抱かせるには十分すぎる変化でした。

新しい時代の幕開け、そして焦り

グローバルクラウドが席巻したかと思えばコンテナが時代の旗手となり 世の中はIaC（Infrastructure as Code）の時代の幕開けとなっていました。 作業の自動化、人的ミスのない再現性、バージョン管理、 我々が苦労して手動で支えてきた内容が、今ではきれいにコードで完結するようになってきました。

新しく業界に入ってくる若者たちはこれが当たり前かのように周りにある時代、刷新された知識で業務をこなし始めていきます。

そんな中でベテランと名の付く座に安座しているのであれば、 偉そうにこれらの知識も「どや顔」で弁舌しなければメンツを保てないわけで、 ChatGPTとかで非常に表面的に「コンテナのメリットとは？」みたいに調べて知った気になって、 「何となくどこでも動かせるポータブルな技術だよね。お前ら、まだ手動でやってんのか？」 と「どや顔」で言ってはいるものの、 実は自分は何も動かしたことがない虚構の存在になりつつある自分がいました。

そんな自分に嫌気がさし、夜中にふと目が覚めると、「コンテナ 初心者」「IaC やり方」と検索窓に打ち込んでは、溜め息をつく日々。 ただ、物理の世界で生きてきたおじさんにはこのコンテナというものが、 どうにも宙に浮いた、つかみどころのない幻のように感じられたのでした。

重い腰を上げ下げしてようやくKubernetesへ

「石の上にも三年」といいますが、重い腰を上げるのに5年かけてようやくKubernetesを勉強する気になりました。 このきっかけといえば、実は異動になって業務で使うことになったことも大きいですが、何よりも、 自分よりも年上のベテランエンジニアがKubernetesを使っていたことが、大きな精神的な転換点でした。 若い世代に負けることよりも、自分よりも人生の先輩たちが軽々と新しい技術を使いこなしていることに驚きを覚えたのです。

それは、自分自身が長年の経験に胡坐をかき、新しい時代の変化を傍観していたことへの強烈な否定でした。 いつのまにか、自分の得意なインフラは、主流の座を新しい技術に明け渡し大きく様変わりしていました。 若いエンジニアたちの軽快なフットワークについていけない自分を、心の中では「仕方ない」と割り切ろうとしていたのです。 しかしその先輩の姿は、そんな言い訳を打ち砕きました。 積み重ねた経験からくる自信と、新しい知への探究心がそこには見えました。 その時、私はこのままではいけないなと強く感じたのでした。

重い腰は上がりました。そして、Kubernetesという、今まで手をつけてこなかった新しい世界の扉を叩くことにしました。 別に40代からでも遅くはないのです。今からでも大丈夫。 同じような不安や焦りを抱えている方々にとって、少しでも勇気を与えられる存在になれたら幸いです。

金はかけるがコスト感をもつ

細かい技術の話をしてもあれなので私が今も続けられている勉強方法について記載します。

まずは、多少お金をかけることです。 これはジムと同じ理屈で、無料のサービスだけではどうしても甘えが出てしまいます。 多少でもお金を払うことで、「せっかくお金を払ったんだから、元を取るぞ」という気持ちが生まれるからです。 あと、重い本を何冊も買うよりもマシに思えたからです。

ただし、コスト感は徹底的に意識しています。 無駄な出費は避け、できる限り節約するのが自分のルールです。

そんな中で選んだのが、AWSのマネージドサービスである EKS（Amazon Elastic Kubernetes Service） でした。 グローバルクラウドのサービスに触れられるので、まさに一石二鳥。 EKSの裏側にある難しいコントロールプレーンのことは一旦忘れて、まずはとにかく Deploymentを動かしてみる。 そこに重きを置いて、手を動かして遊んでみることにしました。

※ちなみに、油断するとすぐに1万円に到達してしまうので、かなりの注意が必要です。 常にコストをモニタリングし、不要なリソースはすぐに削除する癖をつけなければなりません。

手始めにやったのは、「Hello, World」のコンテナを動かすことです。

まずは、シンプルなアプリケーションを動かすための Podと、そのPodを管理する Deploymentを作ってみました。 YAMLファイルにたった数行のコードを書くだけで、いとも簡単に立ち上がる。 その瞬間の感動は今でも忘れられません「おお、動いたわ～・・」。

次に、そのコンテナに外部からアクセスできるように Ingress、Serviceを設定しました。 この一連の流れを体験したことで、これまで漠然と「宙に浮いた話」に感じていたコンテナの世界が、 少しずつ現実のものとして手触り感を持つようになりました。

（参考）AWSのマニュアルにあるゲーム（2048）をデプロイしてみる

HelloWorldが動かせたら、次は実際にAWSが公開しているサンプルアプリをデプロイしてみると面白いです。

docs.aws.amazon.com

アプリのDeploymentはたったこれだけです。ほかにServiceとIngressはありますが、その十数行でkubernetesで実際にゲームが動きよりリアルなイメージとなってきます。たったそれだけで。 ※読むだけではコードの羅列ですが動かすと世界が変わります

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: game-2048
  name: deployment-2048
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  replicas: 5
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
        - image: public.ecr.aws/l6m2t8p7/docker-2048:latest
          imagePullPolicy: Always
          name: app-2048
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "0.5"

このYAMLをapplyすればOKです。

kubectl apply -f 02-deployment.yaml

あとはブラウザから確認すればゲームが動きます！

難しく考えず、実は根本はあまりかわらないよ

物理インフラで培った経験は、決して無駄ではありません。 なぜなら、目に見える物理的な機器から、コードという抽象的な概念に変わっただけで、 サービスを安定稼働させるという本質は何も変わらないからです。

むしろ「ベテラン」は昔ながらの苦労を乗り越えてきたからこそ、新しい技術の効率性や便利さにより深く感動できる。 そう気づいた時、「時代遅れになってしまうのではないか」という焦りではなく、新しい知識を手に入れた喜びで満たされていました。

おわりに

ということで終始ポエムな記事で物足りなかったかもしれませんが、たまにはこういう記事もありなのかなと。。 現在はGitHubにソースを上げるとGitHub ActionsでECRにイメージが自動で作成されるようになっており、 次はこれ以降のCICDでも作ろうかなと思っています。 わからないことは今やAIにガンガン聞けますし そして何より、わからないことを恥ずかしがらずに行動することこそが、これからのエンジニアに必要な姿勢なのだと、あらためて感じています。

もしこの記事が、少しでも「やってみようかな」と思っている方の背中を押せたなら、うれしい限りです。