『IT自動化の力でビジネス加速を全ての企業に』

”IT自動化の専門会社”、リアルグローブ・オートメーティッド（RGA）技術ブログ編集部の馬塚です。今回のnoteは、これまでの技術情報の配信から毛色を変えて、インフラエンジニアでない技術者でも Kubernetes を活用してコンテナアプリケーションの開発ができるようになったお話をエピソード形式で投稿します！

このnoteを読んで、自分もコンテナ技術の活用にチャレンジしてみよう！と思ってくださる方がいらっしゃれば嬉しいです。
前編と後編の2本立てでお届けいたしますー。

――――――――――――――――――――――――――――――――――

私がインフラエンジニアとして駆け出しの新人だったころ、Kubernetes (以下、k8s) については「すごく便利なツールがあるらしい」程度の知識しかなかった。それまでは web アプリ開発などコードを書く業務をメインでやっていたので、インフラ関連は正直なところ疎い。k8sはdocker imageを利用して、アプリを公開出来るようにすることができるのかな、という漠然とした認識はあったものの、特に業務で触れる機会が無く後回しになってしまっていた。

そんな状況がしばらく続いていたのだが、ふとしたことから「今回はk8sを利用したアプリ環境を作ってみないか」という話が先輩技師から降ってきた。「まぁ、新しいものが使えるという機会は非常に面白そうなことだ、これを機会にちょっとk8sを触ってみよう」と軽い気持ちで勉強を始めてみたのだが……実はこれがなかなかやっかいなものだった。

とりあえずk8sを学習してみる

手を動かして何かをデプロイする前に、とりあえずk8sとは何かを知ろうとしたが、なにせ未知の概念が多すぎた。 はじめの感触としては、殆ど未経験者の私には、このk8sの素晴らしさを体験するには時間がかかりそうだ、と感じた。

dockerとk8sの大きな溝 

k8sはdocker imageなどを便利に扱うものだから、大体似たような感じのものかもなぁ、と高を括っていた。しかし、k8s 独自の概念が思っていたよりも多く、それが理解の妨げになっていた。例えば……、
・Pod, Node, Service, NameSpace ... なにそれ？
・Master Node, Worker Node とは?
・image をデプロイするだけじゃダメなのか？
・yaml に書いている設定が多すぎて分からない……
端的に言ってしまえば、インフラの知識が乏しい + dockerで何となく知っている部分があるという状況から、k8s全体の構造を見る前に、頭の中で混乱が起きてしまっていたのだ。

抽象化という砦

これはいけない、「全体の構造を知ってから、お試しでデプロイしてみよう」と思っていたが、それよりもこのk8sの独自の概念を知らなければ……。このままだと何だかよく分からないパーツで何となくおもちゃを作り、誰も理解できない（抽象的現代アートのような）美術品のようになってしまいそうだ。

しかし、どうしてk8sが素晴らしいものだと言われているだろうか？少なくともk8sを使うと様々嬉しいことは必ずあるはずで、k8sが目指しているゴールもあるわけだ。そういったものを見据えた上で、基本的なパーツを知ればk8sを理解する手助けになるんじゃないか、そう思い公式 HP の紹介文を読んでみる。

公式での紹介は ”k8sはコンテナを中心とした管理基盤です” とあり、containerと呼ばれる仮想マシンでデプロイするものらしい。これに近くて、馴染み深いものとしては docker imageを利用した本番環境のデプロイがある。そして、どうやらcontainerを運用する過程では、いくつもの抽象的な概念を使った構成をしないと運用に支障をきたしてしまうようだ。

containerからPodへ

container自体は近年注目が高まってきている。簡略して言うと、containerはコンテナ型仮想化という技術で作られた仮想マシンである。さらに、このcontainerは “image” と呼ばれるファイル群から作成されたものだ。

そして、どうやら Pod はこのcontainerをグループ化したもののようだ。

containerは一つでも動作はするが、実際にアプリを開発するとなると、フロントエンドとバックエンドとそれぞれの役割を担うcontainerを作り、複数のcontainerを組み合わせて開発をするだろう。 Podではそれらをグループとして取り扱うらしいが、もちろん1つのcontainerをPodとしても問題ない。

図1: Podの構成イメージ

ここで注意したいことは、実際にデプロイをするにあたって、私達はPodを宣言的設計という”抽象化”をしなければいけないこと。つまり、k8s にレシピを教えるわけだ。実際のPod はこのレシピを元にk8sが作ってくれる。イメージとしてはPod Aというレシピを人間からk8sに教え、k8sはPod Aというレシピに従ってPod A-1, A-2, A-3のように作ってくれるのだ。

図2: Podのdeploy イメージ

しかし、なぜレシピという宣言的設計を扱わないと行けないのだろうか？　自分でやってしまったほうが多少は面倒くさくても、何を扱っているかを意識できるし、そちらのほうがいいんじゃないか？

Pod は増えるよ、どこまでも

しばらく考えていると、「なぜわざわざPodという抽象的な定義を作ったか」という疑問に突き当たる。が、この疑問について考えていけば、k8s の基本的な考え方や嬉しいところがわかるんじゃないかという期待もあり、改めて立ち返ってみる。 

k8sで利用するcontainerは軽量で貧弱な仮想マシンである。これを本番環境で使うというのは筋が合わない用に思えるほどだ。この点だけで話をすれば、containeなんて面倒な技術を使わずに、実際のマシンに直接アプリをデプロイしたほうが安定して動くのではないか？

モチベーションとしては手元で開発しているdockerという環境を本番でも使いたいわけだが、k8sのcontainerとしてデプロイすることは、これまでの（直接アプリをデプロイする）スタイルと比べると安定性がないように思える。

調べを進めると、k8sはこの軽量なcontainerという仮想マシンたちをPodとしてまとめて、状況に応じて複製と削除をしてくれるらしいことが分かった。なるほど、少しずつ Pod をなぜ定義したいかが見えてきた。続けて、これの何が嬉しいか代表的なものを調べてみた。

・アクセスなどの負荷に応じて、Podを増減してくれる。必要なときは大量にPodを作成し、不要になったら削除をすることでリソースを効率的に使える。
・仮に複製されたPodで何らかの異常が起きたときに、このPodを再起動、または再生成することで自己回復を行える。そのため耐障害性に優れている。

などと言った機能を搭載し、非常に柔軟性のある環境を作ってくれるようだ。さらに、（これら程ではないが）そのほかにも嬉しい点がたくさん見つかった。

となると、やはり抽象的なPodという定義は非常に嬉しいもので、私達の「開発環境である docker containerをそのまま本番へ持っていきたいよね」という願望をk8sはうまく叶えてくれそうだ。そして、便利さを求めるには、この抽象化という作業とひたすらに向き合うことになるわけだ。

Pod のAuto Healing / Auto Scaling

なるほど、私達はk8sが持つこの軽量なcontainerをうまく利用する方法によって、非常に柔軟性の高いアプリケーションの本番環境が得られるわけだ。やっと、Podが分かってきた。

抽象的なPodを定義すれば、アクセス過多や意図せぬエラーが起きたとしても、k8sは自動的に対処を行ってくれる。これは具体的な操作ではなく、抽象性がある手法だからこそできるとても嬉しいことなのだ。つまり、人間の管理するコストをマシンにある程度任せつつ、スケーリングも出来る！

少し学んだだけでk8sがとても便利なツールだと分かってきた、これからフル活用してみたいと思ってみたのだが……、ここで新しい疑問が。

「Pod AからPod A-1, A-2, … と作ってくれるらしいけど、どこにあるか分からないPodにどうやってアクセスするんだ？」
（次回に続く）
――――――――――――――――――――――――――――――――――

執筆者プロフィール：合屋 純
九州大学大学院理学府修士卒 大学院で物理学を専攻し、数値計算プログラムに触れたことをキッカケにエンジニアリングに興味を持つ。
現在はリアルグローブ・オートメーティッドにて、コンテナ関連技術や自動化ツールの導入業務に従事。

【ご案内】
ITシステム開発やITインフラ運用の効率化、高速化、品質向上、その他、情シス部門の働き方改革など、IT自動化導入がもたらすメリットは様々ございます。
IT業務の自動化にご興味・ご関心ございましたら、まずは一度、IT自動化の専門家リアルグローブ・オートメーティッド(RGA)にご相談ください！

お問合せは以下の窓口までお願いいたします。

【お問い合わせ窓口】
株式会社リアルグローブ・オートメーティッド
代表窓口：info@rg-automated.jp
URL：https://rg-automated.jp

（編集：馬塚勇介／校正：水谷裕一）