コンテナ技術でクラウドの運用はどうなる? ー 後編

前編から読む

2018年11月開催のマジセミ「Docker、Kubernetesなど「コンテナ技術」のクラウドサービス(AWS、Azure、Google Cloud)での活用と、コンテナ時代のシステム運用」での講演内容をご紹介します。仮想化技術であるコンテナの運用現場について語りました。

今回の本題はコンテナです。コンテナがなにかについては別のセッションで触れられているので、私からは触れないですが、私が今お話したような流れで、従来のノリでいけるのかが僕自身もまだまだ疑問なところがあるんですね。

そこで、我々はどうしていくのかについてこれからお話しします。おもしろいなと思うんですが、オンプレ、IaaS、コンテナのイメージについて、みなさんが描いている絵が微妙にみんな違います。この絵が正しいかどうかは置いておきますが、みんな違うんですよね。変遷でいくと、オンプレやIaaS、PaaS、SaaS、コンテナがあります。

ざっくり運用者の視点から見るとどうか。開発者ではなく、運用者から見ると、オンプレは実は楽なんですよ。IaaSはまあまあわかりやすい。コンテナになると正直よくわからないとという気がします。

順次見ていきますと、例えば、オンプレの構成は変わらない。上から下まで全部管理対象だし、自動化しようと思ったらがんばればできるのがオンプレの特徴です。

スライドの63パーセントという数字は「オンプレがこの先増えますか? 減りますか?」というアンケートの答えですね。63パーセントが「たぶんこのままオンプレ使います」と言っています。意外と「へ~」ですよね。

オンプレの監視や運用について

オンプレの監視をどうするか? ご存知のとおりですね。UOMでも監視できますが、JP1やZabbix、Nagiosなど、いろいろなオープンソースもあって、ずっとオンプレの環境に対して見にいくので、当然、従来型の仕組みでできます。

オンプレの運用は? プロセスやサービスの再起動とかクラスタの切り替えですね。クラスタサービスとか入っているかもしれないですけども。

こういったものを、いわゆる手順書ベースでやっていくのが基本的な考え方です。最近はRBAでコマンドラインを自動化していく感じになってきました。

地味にオンプレで面倒なのは、閉域接続をどうするのか。だいたいオンプレですから、自分たちの箱の中にものが作られていきますからね。

そこに対して我々みたいにアウトソーシングする人たちは、リモートから入らないと仕事できないので、接続する回線を作らないといけない。一般的には閉域接続や広域イーサなどでつないでいきますけど。

各社のモニターツール活用事例

こちらはIaaSです。ご存知のとおり、スライドでは年率20パーセントくらいで成長することが示してあります。20パーセントではなく、もっとすごい数字を示しているところもたくさんあります。成長しているという意味ではみなさんのご理解のとおりですね。

IaaSは作る側からしてみたら動的に構成が変わったりすることもあって、いい面もあります。運用から見て、いいところはOSより下は基本的に見ない。

また、意外とAPIが出てくるので、自動化はしやすいです。コマンドラインじゃなくてAPIを実行すると、いろいろできるのが大きな特徴です。

IaaSを監視しようと思ったら、あまり気にしなくても従来型の監視システムでだいたいできます。OSが見えているので、エージェントを突っ込んだり、リモートでログインができますね。オンプレかどうかは、あまり考えないですね。あまり問題にならないです。

強いて言えば、VMwareなどを使った場合にハイパーバイザーの監視をどうするのか? 弊社はVMwareベースの「VWシリーズ」を提供しています。

こういったESXiに対するログの監視は、APIベースで取ります。リソース、ログ、構成情報を取るのなど、今はこういったものも必要ですね。

だんだんレイヤーが最近になってきました。PaaSやSaaSなど、言い方はいろいろありますけど、こうなってくるとどうなるのか? 実は先ほど出てきたような監視ツールで監視はできないです。なぜか? それぞれ各パーツでしかないことを考えると、そもそもログインでできないからです。

そのため、我々としては、どうしようとしているか。AzureMonitorやStackdriver、CloudWatchなど、各社がいろいろなモニターツールを出されていますけど、そういったところと連携させようとしています。

例えば、メールやAPIで取り込む。CloudWatchはUOMでは標準的にメトリックを取れたりします。こういったものがないとPaaSやSaaSを見られな いです。

ただ、ご注意いただきたいのはSaaSやPaaSを細かく下まで見る必要があるのか? ということが本質的にあります。オンプレと同じように全部見なきゃいけないというのは少し間違っています。そこはご留意ください。

閉域接続のメリット・デメリット

それでは、IaaSの運用の話に戻します。基本的にはリモートログインベースでやっていくのはいいと思います。オンプレと同じです。しかし、APIが出ていますから、各社のAPIをうまく使っていくほうが楽だと私は思っています。

我々としては今ちょうど作りかけたところではありますが、年明けくらいに各社のクラウドをCLIベースで実行できるものを順次リリースすることにしています。コマンドラインでオペレーションする時代ではないと思っているので、こういうふうにしていくのは必然だと思っています。

そしてIaaSの接続が難儀です。AzureやAWS、Google Cloudなどがあったときに、これとどうやってつなぐのかがなかなか難しいんですね。例えば、IIJだとExpressRouteでAzureにつなぐことや、DirectConnectでAWSをつなぐことはもうできています。

そのため、監視の仕組みであるUOMもこういったものに接続すべく、近々リリースします。マルチクラウドへの接続はやはり必要ですよね。

ただご存知の方もいらっしゃいますが、これらの接続はコストが高いんですよ。コストを重視するなら、VPNという選択もなくはないですが、VPNはなかなか設定が面倒くさいです。できないことはないですけど、ちょっとハードルが高いと思います。

ちなみに「IIJ GIO」というブランドでやっています。プライベートリソースをVMwareベースで作っているのがありますが、こういったものはIIJの中だと標準接続でプライベートでつながれています。これは宣伝ですけど、そんなこともやっています。

コンテナ管理を自動化する重要性

そしてついにコンテナまでたどり着きました。最近の話ですね。いろいろなものがどんどん変えられる。すぐ作って潰せるのがいいところですよね。コンテナ自身が管理してくれます。この状況下でコンテナをどうやって監視しますか?

結論ですが、従来の監視じゃ無理です。やってやれないことはないですが……。スクラッチ&ビルドされるものに対して、監視を1個1個すれば可能だと思います。

しかし、何の意味もないですよね。今回のコンテナの講演を聞いていただいたら、みなさんわかると思います。違う方式を考えざるを得ないと思います。

じゃあどうするか。コンテナはコンテナ自身で見てくれますから、コンテナ自身が見てくれた情報を集めるものが必要じゃないですか? 自分で見に行く時代はそろそろ終わりだと思います。

コンテナから来る矢印が、今までと違って、逆になっているんですね。これは情報を拾ってあげる受け口がないと運用できなくなりませんか? さらに運用するときには従来型のログインする作業はできないことはないですが、やはり難しいんじゃないかと思います。

そもそもコンテナ自身が管理してくれているんですから、いっそのこと任せてしまったらどうでしょうか? 運用屋の私が言うのもどうかと思いますが、たくさんコンテナの接続を切りますから、従来通りでやるのは無理です。1個1個手順書作るのは絶対あり得ないですよね。

管理してくれているコンテナ自身を制御する方向に持っていくなど、もっと上段の管理が必要。すなわち統合的な運用を考えないといけないなと思っています。

そういったコンテナへの接続はどうするのか。インターネットで接続するのもいいかもしれないですけど、やはり閉域がいいですよね。ずっと運用をやってきた僕としてはやはり閉域が一番だと思います。

マルチクラウド時代の運用管理をどうするか

こうして、いろいろな状況を見てきました。クラウドは多様化しています。そして、複数のクラウドが使われます。

これは弊社のお客さんのアンケートです。73パーセントくらいのお客さんが「いろいろなクラウドを一緒に使います」とおっしゃっています。我々のお客さんなので、IIJ GIOを使ってくれると一番ありがたいんですけど、そういうお客さんはあまりいないんです。いろいろなクラウドを一緒に使っています。

なぜか。「各社さんがいろいろな長所があるじゃないですか」「どこか1択より、あれとこれを使いたくなりますよね」。当然だと思います。どうしてもマルチクラウド化は避けられないんですね。

そこに今回のお題です。コンテナが入ってきたとなると、冒頭の絵と似ていますが、オンプレやメガクラウドがあって、その上にコンテナなどがあります。いろいろなところに行ったりするわけですよね。オンプレまで降ってくると、とてつもなく複雑ですよね。運用屋としてはあまり考えたくない状況ですね。

簡単に言えば、各社さんでできることがバラバラになってきています。それぞれできることが違うので、これをどうにかまとめる仕組みが必要ですね。

マルチクラウド時代の運用管理をどうしていくか。ざっくり絵で描きました。統合管理をするためのツールを置かないとやはり厳しいでしょう。

その下にぶら下がらなきゃいけないものは各メガクラウドやオンプレ、そのほかに拠点やVPN設備もあるので、いろいろなものにつながらないといけないです。

なぜならばシングルで使う人は絶対いないですし、オンプレもなくならないですから。運用管理する人たちはどこかを見ていればよいですが、絶対ならないです。統合的に見ないと疲弊します。

どうやるかと言うと、IIJはネットワークの会社なので「IIJ Omnibusサービス」という接続サービスがあります。こういったネットワークサービスと組み合わせていただくことでいわゆるメガクラウドと接続できて、オンプレとも接続できます。WANの構成でも、拠点でも接続できます。そういったところまで考えていかないと、この先の運用者はいろいろなツールを見なきゃいけないですからね。

今回のセミナーでご紹介があったいろいろなツールは、みんなそれぞれ個性があってすごくいいと思います。しかし、それを全部知っていて、運用するかと言うと難しい気がします。

サブスクリプションとサポート統合

そして、地味に忘れちゃいけないのはサブスクリプションですね。今回課金の話は出なかったんですけど。各社のクラウドを使っていると課金処理は、みんなバラバラなんですよね。円建て・ドル建てなどに対応しなければならない。

それを都度、従量で計算するのは非常に大変です。そのため、こういった課金管理の部分まで含めて、統合的に処理しないと、情報システム部門の現場の仕事で課金管理のエクセルがまた増えるわけですね。こういうものまで含めて統合的にやらなければいけない。

そして最後はサポート統合です。当然、契約はみんな別ですから、一般的にはメガクラウド全部とサポートの契約を結ばなきゃいけなません。こういったサポートも含めて統合的にやらなければいけないと思います。

各社へのハンドリングを自分でするのか、誰かにお願いするかも気にしていく必要があるでしょう。

今後もSaaSでさまざまな機能を実装

今回はいろいろなお話をさせていただきましたが、IIJではこういった機能をSaaSというかたちでご提供しております。まだまだ進化途中ではございますが、放っておくとSaaSなのでどんどん機能が上がります。

当然サプスクリプションモデルでやっていますので、いろいろな必要な機能を厳選してパッキングして販売させていただくかたちでご提供しています。

もしかすると、競合他社の方も今回ご参加のみなさんの中にいらっしゃるかもしれないです。私は運用者はみんな仲間だと思っています。OEM・リブランドみたいなかたちでこの基盤そのものをご提供させていただくビジネスもやっています。

今回は、いろいろな情報がありましたが、まだまだ僕らも作り切っていないところもありますので、「一緒にやっていきたい」などの話がありましたら、ご検討いただければなと思っております。

これで私の話は終わりにさせていただきたいと思います。どうもありがとうございました!

前編から続く