Dockerとコンテナがざっくりわかる!『Kubernetes完全ガイド』青山さんにflexyの麻衣子お姉さんが聞く! #Docker編

flexyマーケの麻衣子お姉さんが、現場の最前線で活躍するエンジニアへ会いに行くこの企画。

「聞いたことあるけど良く分からない」「ざっくりと教えて」という非エンジニアならではの問いに答えてもらいます。技術書やWebで調べてもいまいち難しくて理解できないあんな技術やこんな技術。プロに優しく教えてもらいましょう。

今回のテーマは「Docker」。麻衣子姉さんは、なぜ巷でそんなにみんな使っているか知りたい様子。サイバーエージェントの青山真也さんに伺いました。

Dockerについて教えて!

麻衣子:『Kubernetes完全ガイド』の著者の青山さんに、「Docker」について教えてもらいに来ました!

青山:Dockerの利点を理解してもらうために、それよりも昔の、サーバのお話から始めます。

ベアメタルのサーバ、いわゆる物理サーバの場合にサーバが必要になったら、物理的なサーバを買う、データセンターに設置し、設定をしていきます。自動的に構築する手段はあったんですけど、割と手動で構築する部分が多いものでした。OSを手動で入れて、そこにどのようなアプリケーションやソフトウェアを入れていくのか、自分たちで一から手作業やスクリプトで自動化させることをしていきます。物理サーバの難点は、サーバの負荷が高くなってきたからサーバを増やそうとなったときに、購入から設置、設定まで必要になり、1台増やすだけでも半日くらいはかかってしまい、遅いと数ヶ月くらい前には購入しておかないといけないということも起こりえます。

プロフィール


青山真也

サイバーエージェントで社会人4年目。現在は社内のプライベートクラウド構築に携わるほか、Kubernetesのマネージドサービスもオンプレミス上で作って提供している。副業でもKubernetesの仕事を複数行っているほか、コミュニティ活動、DockerやKubernetesに関する本も2冊出版するなど積極的に布教活動を行う

麻衣子:オンプレミスからクラウドに移行する話、よく聞きますね。自社にサーバーを設置するオンプレミスですと、やはり事業のスケールでトリガーになることがあると聞きます。

青山:当然こんな仕組みだと、事業を拡大しているフェーズであれば、対応しきれずに成長機会を逃してしまうことにもなりかねません。特にWeb系のスタートアップであれば、この対応力は必要不可欠。 そこで出てきたのが、いわゆるクラウドという概念です。クラウドは、インターネットの雲があるイメージです。利用者から見ると、雲の先に無尽蔵なサーバのリソースがあって、実際にサーバが欲しいとGCPやAWSなどのクラウドのプラットフォームにリクエストを投げ、雲の向こうに必要なサーバを払い出してくれる、みたいな仕組みです。そのため、サーバが必要となったら、いつでもその1分後にサーバを作って渡してくれるみたいな便利なものです。

麻衣子:かつてPhotoshopとかIllustratorをパソコンにインストールして使っていましたが、今はAdobe Creative Cloudになったじゃないですか。「クラウド」の利点やサービスがスケールしたインパクトは大きいですよね。

聞き手


麻衣子お姉さん
flexy編集部
サーキュレーション flexy事業部 マーケティング担当
上智大学文学部哲学科卒。前職は、代表としてハワイのオアフ島で起業していました。海外生活は、オーストラリアとハワイ合わせて合計7年。日本に帰国後、サーキュレーションに参画し、今はflexyのマーケティングとして特にインターネット(SNSやメディア)を担当。

青山:そうですね。今まで自分の手元にあったものが、全部インターネットの向こう側に基本的にはある。クラウドは、インターネットを介して向こうに置いてあるのものを使うってことなんです。

ゲームの場合だと、PlayStation 4やNintendo Switchなどハードウェア自体を買ってきて手元で遊んでいます。それが、最近Googleが出したStadiaというクラウド上にあるゲームプラットフォームだと、ゲーム機がクラウドの向こうにあって、コントローラーと画面だけ手元にあればゲームができるという世界になっています。GoogleがPS4の本体を大量に用意してくれていて、家のテレビにそれをつなげるようなイメージです。

DVDがNetflixなどの動画配信サービスになったり、紙の本が電子書籍になったり、あらゆるものをインターネット越しに利用する世界になってきています。

麻衣子:改めて、ITの発展には欠かせないものだったんですね。

青山:クラウドがどういうものが分かってもらえたので、一旦物理サーバの話に戻します。

物理サーバの場合は、どういうサーバが必要なのかを考えた上で、基本的にはOSを入れた後に、自分でその要件に合わせて環境を作っていかなければいけません。「イメージ化がしづらい」という問題です。物理サーバのときは手動で構築をやっていたのですが、実際に作るサーバは、だいたい「こういうの」というのが決まってきます。そのような「イメージ」を用意しておいて、増やしたいときはそれをコピーしちゃおうという考え方が出てきました。この仕組を使って、クラウドの時代になってくると、サーバを1台から3台に増やすのも簡単だし、人間の手作業の構築時に起こるようなミスも起こらなくなります。これが、もう一つクラウドのいいところです。

Docker4 物理サーバでは環境を作るのに半日〜数ヶ月もの時間がかかるが、クラウドであれば数分で終了する。サーバを1台から3台に増やすというのも簡単だし、人間の手作業の構築時に起こるようなミスも起こらない

クラウドの雲の先に払い出されるサーバは一般的に仮想マシンです。仮想マシンのイメージ化というのも、もちろんできるのですが、あまり簡単にできないのです。イメージ化するためには、結構面倒な処理をして、やっとイメージを作れます。実際に作れば簡単に複製はできるようになったのですが、いまいち流行りづらかったのが実状です。その面倒な処理を簡単にできるのがDockerの魅力なのです。

麻衣子:ちなみに、サーバを複製すると何が嬉しいんですか?

青山:ビジネスがどんどん成長してくると、サーバ1台だとさばききれなかった処理を複数台のサーバでどんどん処理をさばく必要が出てきます。スケールアウトして処理をさばけるようにしていかないといけないのです。

例えば、レジで考えてみましょう。1台のレジと1人の店員がレジ打ちをして対応しています。そこへやって来るお客さんのリクエストに応じてレジ打ちをし、レスポンスを返していきます。ただし、1人の店員だけだとお客さんがたくさん来た時に対応しきれません。その場合、複数のレジと複数の店員を追加すればスムーズに対応できるようになります。店員を追加すると言っても、レジ打ちをしたことがないバックヤードの店員や警備員を集めてもこれまで同等のレスポンスが返せません。レジの基本的な使い方に加え、そのお店独自の割引のサービスなどもマニュアル化されて、レジ担当の店員はそれを覚えているはずです。「そのノウハウがインプットされた店員」をイメージ化しておき、必要になった時に同じスキルを持った店員を一気に複製する、という事ができればスムーズなレジ対応が出来ます。サーバの処理もこれと同じです。

麻衣子:その複製はどれくらいでできるものなんでしょうか?

青山:仮想マシンの場合でも、ちゃんとイメージ化をしておけば、早ければ1分、遅いと5分ぐらいの感覚です。しかし、実際にどれくらいの人がイメージ化をしているかというと、実際あんまりしていないんですよ。イメージ化をしていないとどんな問題が起こるかというと、1分〜5分と言っていたのが、30分とかになります。しかも、本当に同じ環境が出来上がっているかどうかも厳密には分からないんです。イメージ化をしておけば、全て同じ環境が出来上がるので、こんな不安を抱く必要もありません。レジの話でいえば、新たに教えた社員とクローン人間くらい違います。

イメージ化をきちんとしていても、早くて1分。それが、Dockerで使われているコンテナという仕組みの場合は、数秒レベルに短縮されます。そのため、突発的にサーバへのアクセスが増えたとしても、急に1,000人レベルのお客さんがレジに現れたとしても、レジ打ちの店員を100人、1,000人に一瞬で増やして対応できるのです。このようなスケーラビリティというのが、最近のシステムでは求められるようになっています。1分や30分かかっていたものが数秒になるのはインパクトが非常に大きい。無駄なサーバの資源を確保しておく必要もなくなります。

1分ほど複製にかかる仮想マシンのイメージ化にくらべて、Dockerであれば数秒で完了してしまう

仮想マシンのイメージ化が簡単ではないという問題があったのですが、コンテナだと非常に簡単に出来てしまします。ケースバイケースですが、1時間位かけてイメージ化していたものが、簡単に3分位で出来てしまうイメージです。

麻衣子:イメージはどうやって作るんですか? 

青山:仮想マシンの場合は説明も面倒なので割愛しておきましょう。それに比べ、Dockerであれば簡単ですよ。

Dockerの場合は、ペライチのファイルを書いておきます。Dockerfileというファイルを書いておくと、あとはコマンドで docker build というコマンドを実行すると、イメージが作成されます。

麻衣子:今は、こっちのやり方を覚えるのがおすすめ!って感じですね。

青山:はい、その通りです。

麻衣子:利点は他にはどんなものがありますか?

青山:この作ったイメージは、Dockerというものがインストールされているサーバであれば、どこでも基本的に同じように動くことが保証されているんですよ。そのため、GCP上でも、AWS上でも、オンプレ上でも、同じものが動いてくれるメリットがあります。サーバだけでなく、MacやWindowsなどの手元の環境でも、同じように動くことが保証されています。

麻衣子:どこでも使えるのですね。

青山:あと、イメージ化周りで言うと、実はDockerだけではなく、Docker以外のものでもイメージを作れるようになっています。このイメージがどういうフォーマットになっているか、どういう形式になっているかというのは、OCI(Open Container Initiative)のバージョン1.0で仕様が定められています。これにより、こういうイメージを作ったら、そのイメージはどのように動くのか、どういうファイルで構成されているか、などが決まっています。そのため、Dockerでイメージを作ることもできるし、Docker以外のものでもイメージを作れるようになっています。そして、その作ったイメージ自体も、Dockerで動かすこともできるし、Docker以外のもので動かすことも出来ます。 つまり、もし、将来Dockerがなくなったとしても、Docker以外の別の何かで同じようなことが引き続きできる安心感もあります。

仮想マシンが主流の頃と違い、オープンソース界隈では、お互いに競争はするが共通化できるところは共通化する流れがあります。それぞれ独自仕様にしたとしても、誰も得をしません。その考え方があるため、仕様のようなどういうものを作っていくかはオープンなところでみんなで決めていき、それをみんなで使っていきましょうという流れです。

あとでお話するKubernetesというものがあるのですが、そのKuberneteはCNCF(Cloud Native Computing Foundation)という団体が管理しています。CNCFは、Kubernetes以外にもいろいろなプロジェクトを管理しており、いろいろな共通化の推進も行っています。

麻衣子:CNCFはどこにあるのですか?

青山:CNCFは非営利団体The Linux Foundation傘下のプロジェクトです。Linux系の一番大きくて有名な団体ですね。サーバ系やいろいろなOSSの管理をしています。そこでいろいろな共通化がされているので、先ほど説明したコンテナイメージや、ネットワークとか、みんなで手を取り合って決めていきましょうね、というのが最近の流れです。

このCNCFは、有名どころで言うとGoogleやAmazon、Microsoft、Red Hat、IBM、アリババなど、名だたるIT企業がほとんど入っていると言っても過言ではないくらい、多くの企業が参加しています。そこで、みんなちゃんと意見を出し合って、どういう風に作っていくかちゃんと議論されて作っていっています。

麻衣子:みんなで決めていくとしても、どこかの企業が自社が有利になるように話を進めてしまうようなことは起こらないのですか?

青山:細かく見ていくとなくはないとは思いますが、あまりそのようになりにくい構造ではあると思います。どちらかというと、最初にインタフェースや仕様だけを決めます。例えば、ネットワークはこういう風に作りましょうということだけを決めます。その部分では誰もほぼ反対は無く仕様が決まっていきます。その後、その仕様に合わせた各社独自の製品を作っていくという流れです。仕様としては最大公約数的に作っているという感じなので、できるだけ範囲を広めて作っているイメージかと思います。そのため、そんなに争いごとも起きないのでしょう。

あと、CNCF自体がどこの企業にも属さない団体になっているので、特定の会社のメンバーのみで何かが組織されるとかも、ブロックされやすい仕組みです。

麻衣子:なぜ、みんな自分たちでやらずに特に海外のコミュニティでやっているんだろうと疑問に思っていました。コミュニティでみんなで一緒にやった方が力を持った企業と一緒にできて良いということですね。

青山:あとは、みんなで作ったほうが早い部分は、無駄に争う必要もないし協力していこう、というのが海外の考え方です。そのため、いいものはみんなで使っていき、それで足りないものは、またOSSで公開していく。みんながOSSでいろいろ助け合っているような世界観になってきています。しかし、そういうところに日本人があんまり出ていかない傾向にあるかな感じる部分があるので、個人的にはそこが日本の弱いところだと思います。その状態だと、世界で競争してもなかなか勝てなくなってしまう。GoogleやAmazonやMicrosoftが組んで取り組んでいくような世界観で、そのような風土ではいくら頑張ってもなかなか及ばなくなってしまうので、世界のコミュニティともいい付き合い方をしていった方がいいかなと思います。

麻衣子:みんなで一緒に作っていく感じ、素敵ですね。その他にも特徴はありますか?

青山:Dockerの特徴としてイメージ化がしやすくて複製がしやすい、というところまで説明しましたね。他には、起動が早いという特徴があります。これは複製が早いというところにも繋がります。そこに通じるのですが、軽量という点も挙げられます。イメージのサイズが軽量ということは、複製する際にはイメージをコピーすることに成るので、当然、1GBのコピーよりも1MBのコピーのほうが早いよね、ということです。

麻衣子:複製がしやすいことって、アクセスがたくさん来る時以外には役立つ時はあるのですか?

青山:イメージ化がされていて、複製ができるという状況であれば、みんなが同じものを使えるというメリットがあります。そのため、誰かが作ったものを自分のところに持ってきて、それと連携させるシステムを開発することもやりやすくなります。

あとは、サーバやシステムを作る時には1つのイメージで作るのが昔は主流でした。 いわゆるモノリシックサービス、モノリシックなアプリケーションと言われるものです。その大きな1個の状態から、最近は1個ではなく細切れにして連携させるやり方が流行ってきています。

麻衣子:マイクロサービスですね!

青山:そうです、マイクロサービスです。マイクロサービス化して、それぞれにチームを割り当てて個別に開発する開発手法が取られるようになってきました。これはシステムの規模が大規模になってくると、みんなで1個のものを開発するよりも、みんなで分担して、それぞれ狭まったスコープの中を開発し、それらを連携させたほうが開発の効率が上がるよね、という意図で細切れにしています。

細切れになってくると、自分が開発する範囲は限られるのですが、いざシステムを動かして動作確認をしようとした際には、システム全体が揃っていないと確認できない場合があります。そういう時にもイメージ化がしてあると、自分の手元のMacに全部イメージを落としてきて、それで簡単に動作確認する環境が作れてしまいます。

麻衣子:それを、APIでつなげるんですか?

青山:はい、APIでつながる感じになります。それがDockerですね。

麻衣子:私、最近マイクロサービスの勉強をしていて、マイクロサービス開発の話は新鮮すぎて面白いです。

青山:あと1個補足しておくと、マイクロサービス化しておくと、チームごとに開発したものを更新できるようになります。従来の方式、従来の1つの大きなサービスだと、みんなが更新をして、ここで良さそうという時点でアプリケーションをイメージ化して、一気に更新することが多かったです。そのため、多くても1日に1回とか、数日に1回くらいのリリースが多かったのですが、マイクロサービス化すると、その影響範囲も局所化できるので、どんどんイメージ化して、すぐにリリースする、というのがしやすくなります。どんどん更新できると、開発者が時間やコストをかけて作った付加価値をすぐにユーザーに届けることができ、ビジネス的にも非常にメリットがあります。作ったものはどんどん公開していくいい流れです。

マイクロサービスがコンテナで構成されていると、何か起きてもすぐ戻せるし、何か起きたとしても影響範囲を最上限に留めることができるので、どんどんリリースをしていくマイクロサービスとも相性がよかったりします。また、起動や停止も早いので、最悪何か問題が起きたとしても、すぐに戻せば、ある程度の早さで正常な環境に戻せるのも利点です。

麻衣子:1日何回もリリースするとなると、いろいろな作業が自動化されてないと手作業では追いつかなさそうですね。

青山:その通りです。エンジニアは何かと自動化させることが得意です。特にコンテナ等のインフラ系の技術は、自動化することが仕事と言っても過言ではないくらい。コンテナのイメージ化、負荷に応じて自動的にスケールさせる、そして自動的に戻すとか、だいたい全部自動化させちゃいます。

麻衣子:人力作業をITの力で自動的にやってもらえないかなって、いつも思います。

青山:同じことを繰り返さないということは大事な考え方です。

自動化をする意義はいくつかあると思います。1つ目は、自動化することによって1回限りではなく何度も使い回せ、毎回その恩恵を受けられること。2つ目は、人がやるとミスが起きるという問題を解決できる点。手動で入力するよりも、機械にやらせたほうが正確な作業は機械にやらせるべきです。3つ目は、作り方次第ではありますが、標準化ができる点。こういう枠組みで、こういう風にやりましょう、という枠組みを作り、それを元に自動化すれば、後で何か似ている別のことをやりたくなった際に、そのフォーマットを使い回せることがあります。

自動化の小さい例でいうと、スプレッドシートのSUM関数、あれも自動化といえば自動化。自動的に合計値を出してくれるので、足し算を毎回書かなくて済みます。エンジニアは、自動化できるところは少しでも楽をしたいのです。

Dockerをもっといい感じにしてくれるKubernetes

青山:コンテナ化したらDockerが入った環境でどこでも動かせるようになりました。あとは、コンテナというやつをどんどん横に複製、つまりスケールしていけば、処理性能をアップできて、ビジネスがどんどん成長していっても対応していけます。

しかし、実際にはDockerコンテナは、あくまでもサーバ上で動いています。サーバだと想像しにくいかもしれませんが、みなさんの持っているMac上で動いていると読み替えてみてください。自分のMac上で1万個コンテナが動かせるかというと、そんなには動かせません。そのため、複数のサーバの上でコンテナを10個ずつ動かす、みたいな対応が必要になってきます。

そうなってきたときに、再度さっきと同様の問題が起きてきます。1,000台サーバがあるところに10個ずつコンテナを起動しましょう、となったときに、1台のサーバにログインして順番にコンテナを起動させていくかというと、絶対にそんなことはしません。いい感じにコンテナを配置したいなとエンジニアは夢を見ます。10個起動して、100個起動して、といったら、そのサーバ上にいい感じにコンテナを配置して起動させて欲しいです。

あとは、アップデートしたいな、コンテナの中身を変えたいなと思った時に、1台ずつサーバに入って、全部アップデートの処理をするかというと、そんなこともしません。全部自動的にやって欲しい。1台ずつやってとか、2台ずつやってとか、要望に応じていい感じにアップデートすることをサポートしてくれるのが、Kubernetes等のソフトウェアです。そのような、Kubernetesみたいなソフトウェアはコンテナ・オーケストレーション・エンジンと呼ばれています。コンテナ・オーケストレーション・ツールと呼ばれることもあります。その名の通り、コンテナをオーケストレートするツール。オーケストレートが何かというと、分かりやすいのがオーケストラの指揮者。いろいろな楽器の奏者がいる中で、的確に指示を出して、いい感じの指揮をする。それと同じようにコンテナをオーケストレートするものになっています。

実際のマイクロサービス化されたサービスでは、100個以上のコンテナイメージがあることもあります。それを組み合わせてシステムを作っていくので、1個ずつ配置して、こことここは連携させて、とするのは気の遠くなるような作業です。その辺りを全部いい感じに管理するために、そういうオーケストレーション・ツールを活用していきます。

麻衣子:どうやって指揮するんですか?

青山:そこを気にしなくてよくなったというのがメリットだったりします。本来だったら人間がどうやって指揮させるか考えないといけなかったのを、自動的にやってくれるのです。

麻衣子:なんでそんなAIみたいに頭いいことができるのですか?

青山:Kubernetesは、もともとGoogleの社内で使われていたクラースター・マネージャーのBorgというシステムを元にOSS化されたものなのです。言い換えると、ずっとGoogleが社内で使っていた洗練されたシステムをベースとしてOSSを出してくれているので、洗練されたものなのです。そのため、Kubernetesはわりと何でもできてしまいます。

麻衣子:例えばどんなことができるのでしょうか。

青山:Kubernetesは、どういう風にインフラを作るか、というのをマニフェストファイルと呼ばれるYAMLファイルのコードで定義します。そこに、どういうコンテナを作るか、どのイメージ使うかとか、どのくらい複製するかとか、どういうエンドポイントを払い出すか、という指示を書いていきます。「どういうエンドポイント」というのは、インターネット上に公開されるIPアドレスにどれを使うとか、こういう名前で作るとか、そういう指示です。そのため、ネットワークやストレージ等、従来は手作業で設定していかなければいけなかったものも、ほとんどすべてまとめて、全部抽象化して操作できるようになりました。

麻衣子:このマニュフェストはどうやって書くんですか。

青山:どこでもいいんですが、例えばローカルのMacのテキストエディタで、こういうインフラを作りたい、みたいな指示を書いて、それをKubernetesに登録するという作業をします。そうすると、Kubernetesがそれを見て、ああ、こういう風にしておけばいいのね、と解釈してくれます。

麻衣子:それが指示書みたいな感じなのですね。

青山:隣のエンジニアに、これやりたいって、紙を渡す感じですね。

麻衣子:で、オーケストラしてくれるんですね。

青山:インフラの中は、本当にやろうとすると細かい制御が全部必要なんですけが、それを全部隠蔽した形で、「こんな感じで」みたいに指定すると、全部やってくれる。今までいろいろ人手で細かくやっていたものを、全部自動化されるというのが大きいメリットですね。

ロードバランサーの例をしてみましょう。あらかじめロードバランサーの説明をしておくと、ロードバランサーは負荷を分散してくれる仕組みです。例えば、レジが3レーンあった場合、お客さんが一気に来たら、どうやって並べばよいか正直分からないじゃないですか。何も考えずに並んだら1つのレジに偏っちゃうかもしれません。ロードバランサーは、レジに来たお客さんは、1番へ、2番へ、3番へ、という感じに、うまいこと列の混み具合を考慮して振り分けてくれるものです。

ロードバランサーがないと、お客さんが一気に来たら自分がどこに並べばいいか分からず、どこにも行けなくなっちゃいます。通常は大体ロードバランサーというものを1個作ってあげます。これは厳密に言うと、まさかりが飛んでくるんですけど、これはサーバみたいなものだと思っておいてください。

麻衣子:まさかり?金太郎??

【コラム】 技術的な内容に関して、細かい間違いの指摘をすることを「まさかりを投げる」と呼ぶ。

麻衣子:まさかりが飛んでくるけど、分かりやすく説明をしてくれているのですね。

青山:厳密に言うと違うんですが、これはサーバとかじゃなくて、いわゆるネットワーク機器に当たるものですです。従来、ネットワーク機器の統一された自動化みたいなのがあまりなかったので、そういうネットワークのところもKubernetesで操作できるのは大きなメリットです。今までも似たような自動化の仕組みはあったのですが、これをやるときはこのパターンで、別のこれをやるときはこれで、みたいに、ちょっとずつやり方が分かれていたりしました。それが、いい感じに抽象化されて、統一されたというのは大きな進化でした。

例を1つ出します。ロードバランサーにサーバが3台紐付いているとします。全部のリクエストが3台のサーバに振り分けられているので、サーバをアップデートしたいときに、いきなりサーバを止めてアップデートをすると、アクセス中のリクエストが止まっちゃいます。そういう時には、ロードバランサーからサーバを1台外してからアップデートし元に戻す、という処理を1台ずつしていきます。これを手動で1台1台やるのは大変です。自動化もできるのですが、何かしらの仕組みで自動的にそのような処理を行うプログラムを作ってあげたりする必要がありました。Kubernetesの場合は、さっきの指示書を書き換えて登録してあげるだけ、いい感じにアップデートしてくれます。自動的にロードバランサーから外して、アップデートして、戻してくれます。しかも、戻してあげる時に、ちゃんとサーバが動いているかなとか確認してくれたりとか、どのくらい待ってアップデートするかとか、いい感じにやっておいてくれます。

麻衣子:すべてがいい感じに。

青山:自動的に何かをやってくれる仕組みが、いろいろな箇所にあるんです。そういうところがKubernetesのいいところです。

麻衣子:自動化して空いた時間、何をしたいのでしょうか。

青山:エンジニアが自動化して時間を作るというのは、その空いた時間でもっと何か別の改善をするためです。インフラエンジニアであれば、Kubernetes等を使って、開発のサイクルを上げ、エンジニアがもっと開発をしやすい環境を整える目的もあります。それにより、その基盤上で開発するエンジニアの生産性がどんどん上がってくるので、もっとよりユーザーに価値の高いサービスを作れるようにできるのが自動化のいいところです。

麻衣子:Kubernetesで自動化を進めていると思うのですが、自動化が今後の目指す先はどんなものでしょうか。

青山:やはり基本的にすべてをいい感じにやっておいて欲しいというところです。よく言われることですが、同じことを繰り返したくはないし、できることならミスが起きたときにも自動で回復して欲しいとか。誰にも迷惑をかけないし、ユーザーが不満を覚えるような状況をつくりたくない。他にも、自動化によって開発者が開発しているときに簡単に使えることや、簡単にプログラムやアプリケーションを実行できるようにしておくことが理想の姿だと思います。しかし、Kubernetesもいい感じに指示書を書けば、いい感じにやってくれると言いましたが、昔に比べてだいぶよくなってきたが、もっと簡単にできる方法がさらに登場してきています。今が完成形ではなく、今後もさらに進化していく気がします。

そして、今のシステムの規模はマイクロサービスであれば100個、世界的に見ても500個程度ですが、IT化が更に進むと、複雑さはもっと増してくるはずです。そうなれば、今のKubernetesでは太刀打ちできなくなる世界が来るかもしれません。このように、技術というのはどんどん進化していくと思います。

麻衣子:Dockerの次にKubernetesが出てきました。そして、Kubernetesの次に来るものは、どんな世界だと思いますか。

青山:よく言われるのはサーバレスの文脈です。現在では、サーバをあまり意識しなくてよくなったと言いつつも、キャパシティを考えるときなどにある程度はサーバの姿がまだ見える世界です。それが、もう少し見えない世界というのが来るかなと思います。

麻衣子:サーバレスの世界が来て、もっといい感じになるということですか?

青山:もっといい感じになっていきます。

麻衣子:Kubernetesについて、flexyでも先日CTO meet upを行ったばかりで、注目が集まっていますね。サーバレスの世界はどんな世界でしょうか。 どうもありがとうございました!

神様エンジニアになりたい

麻衣子:flexyメディアは、IT業界の発展のためにCTOやエンジニアの皆さんにフォーカスしているテクノロジーメディアです。
最近は、働き方が多様化して、副業を始める方も増えていますので、お仕事のご紹介もしています。
青山さんは、副業をどのようなきっかけで始めましたか?

青山:3年くらい前に、それまでの登壇内容などをポートフォリオにまとめました。そのポートフォリオを添えて「副業も始めたいな」みたいなツイートをしたところ、声をかけてもらい副業をいくつか始めることになりました。

麻衣子:青山さんにとって、副業はどんな位置づけですか?

青山:本業だけだと、どうしても特定の領域に固まってしまうことが多いです。副業をすることで、違う領域でKubernetesを使ったりできるのは楽しいです。サイバーエージェントですと、エンタープライズ領域がないため、副業先でその領域に携われたりしています。あとは、副業先にもそれぞれすごいエンジニアがいたりしますので、そういう方と話せるのも副業をやる醍醐味だと思います。もちろんこういった経験を本業にも活かせるようにしていきたいですね。

麻衣子:今後の夢は?

青山:「神様エンジニア」になりたいです。

麻衣子:神様!!

青山:入社時にも言っていたのですが、技術に特化した強いエンジニアになりたいという思いです。神様のようにいろいろな力を発揮できるエンジニアを目指し、活動の場を広げたり知識を増やすことをしていきたいです。


この記事を書いた人
仁田坂 淳史
株式会社ZINEの編集者。技術評論社で『WEB+DB PRESS』の編集、mixiで「Find job! Startup」の創刊/編集を経験し株式会社ZINEを創業。テクノロジーの取材が専門分野

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

React

テーマ クラウド入居者管理システムのフロントエンド開発(リモート可)
勤務日数 2-3日/週
報酬 4万円/日
必要スキル React
勤務地 東京
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

Go

テーマ 家族型ロボットのサーバサイド開発
勤務日数 3-4日/週
報酬 5万円/日
必要スキル Go GCP
勤務地 東京
リモート 相談可

AI

テーマ AIを活用した新規事業立ち上げの技術顧問
勤務日数 週1日〜
報酬 5万/日
必要スキル Python、AIの知見、新規事業立ち上げの経験
勤務地 東京
リモート リモートと常駐のMIX

PMポジション

テーマ 複数のプロダクトごとにPMを必要としているため急募
勤務日数 2-3日/週
報酬 5万円/日
必要スキル PMとしての経験、PHP、JavaScript
勤務地 東京
リモート リモートと常駐のMIX
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)