orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

マイクロサービスアーキテクチャーをちゃぶ台返しにするRetty社の設計思想

f:id:orangeitems:20180401100143j:plain

 

Retty社のコンテナの使い方

インフラ基盤のコンテナ化で自分の仕事(インフラエンジニア)が大きく変わるのか?、と危機感を持ちながら日々情報収拾していますが、面白い記事を見つけました。

 

tech.nikkeibp.co.jp

従来システムは口コミ情報の参照だけでなく投稿も可能なので、参照のみの新システムとは単純に比較できない。とはいえ、コンテナでそこまで劇的にコストが下がるのか。半信半疑だったが、単にコンテナを導入しただけでなく、独自コンセプトのアーキテクチャーにしたと聞いて納得した。

 それは、1個のコンテナにシステムの全コンポーネントを入れること。名付けて「全部入りコンテナ」だ。

スポンサーリンク

 

考察

DockerやKubernetesなど、コンテナを使うアーキテクチャが日々進化していることを感じますが、まだ仕事に結びついたことはありません。本番サービスがビジネスと結びついていて絶対に停止できないミッションがある中で、まだまだコンテナでサービスを提供することは本格的になっていない印象です。LAMP構成と呼ばれる、Linux+Apache+MySQL+PHPのような、たくさんの成功事例がある構成だと爆発的に広がるのでしょうが、まだ実験段階のような雰囲気なのは2018年になっても変わっていません。

一部で、コンテナで動かすとどんどん仕様を変えていくWEBシステムの場合は対応が楽だということで、挑戦している記事をたまに見かけるので、個人的にナレッジをためているところです。

で、今回のRetty社の利用方法ですが教科書とは真逆です。コンテナを使う場合は、マイクロサービスアーキテクチャーと言って、一個一個の機能を最小化しなさい、というのが一般的です。

album.cloudit.co.jp

総じていえば、マイクロサービス アーキテクチャによって柔軟性や変化への対応性は高まるが、冗長でオーバヘッドも多い。もともとアマゾンやNetflixが提供するようなシステムを、分散システム上で数多くの小規模チームによって実現するためのアーキテクチャであり、全体としては巨大なシステムを大規模な人数で開発・運営してためのアプリケーションおよび開発体制の分割のための手法ともいえる。

 実は、大企業向けにフィットしている機能であって、WEBベンチャーなどが教科書通りにコンテナを採用すると、かえって無駄が多くメンテしにくくなってしまうということを表しているんだろうと思います。

だいたいの新しい技術は、WEBベンチャーなどフットワークの軽い企業がはじめに採用し、旧来の技術よりも優れた生産性を実現し、そこから大企業に波及していくものです。が、この技術ははじめから大企業向けなので、今ひとつフィーバーしないのだなあ、という発見がありました。

一方で、Retty社のこの記事です。

複数のコンテナに分けると、コンテナの作成や消去のたびに接続変更が必要になる。全部入りコンテナでは、コンテナ間に依存関係がないので、接続変更が不要だ。もちろんこれは、コンテナ間でデータを共有させる必要がない参照系だから可能な方法である。

 さらに、全部入りコンテナではサイジングを単純化できる。コンテナごとに、そこに入れたコンポーネント全体がCPUやメモリーなどのリソースを使い切る。DBサーバーのリソースはひっ迫しているが、それ以外のリソースは余っている、といったムラが起きにくい。

 そのため全部入りコンテナなら、コンテナ1個のCPUやメモリーのサイズを決めたうえで、負荷に合わせてコンテナの数を増減(スケールアウト/スケールイン)させれば済む。APサーバーやRDBといったコンポーネントごとに、サイジングする必要がない。

 DockerやKubernetesのやりたかったこととは全く持って真逆と言えます。現時点においては正しいかもしれないですが、今後のDockerやKubernetesの進化と矛盾していく場面もあるのかもしれない、とも思いました。そこがリスクポイントにはなると思います。また、この構成が通用するシステムも限られるだろうと思います。少なくともデータの永続化を実現するためにはデータ自身はコンテナの外にないといけませんし・・。参照系ということで割り切ったので実現できているのだろうと推測します。

むしろこういうソリューションが出てくるということは、コンテナ提供側も大いに反省しなければいけないとも思います。コンテナを触るとわかるのですが、まだまだコマンドインターフェースでの作業が多すぎます。もっとGUIで簡単にできるようにしないと本格普及はまだまかなと。

そういう意味ではこの前下記の記事でご紹介した、さくらインターネットのArukusというサービスはGUIで制御できますし頑張っているとは思います。

インフラ系システムエンジニアはコンテナサービスの本格化で不要になるか - orangeitems’s diary

これまでの歴史で考えると、VMware ESXiのような無償で使えてGUIクライアントでの操作が前提で、実験的に試すとかなり感覚的に使いこなせる「感じのする」本命パッケージソフトウェアが出てきたら、あっという間に広まりそうな気がします。

クラウド前提、という時点でそのクラウドがなくなったらどうするの、という警戒感が出てきてしまうので、オンプレミスで試せることが普及の鍵なのはこれからも変わらないのではないかな、と思う次第です。今も手元のパソコンで試せるは試せるのですが、コマンドラインベースなんですよね。この辺り、MS-DOSからWindowsの進化と似ている気もします。UIが優れているほうが本番運用に取り入れやすい。運用がコマンドじゃないといけないというのは案外負担だし学習コストが高いんですよね・・。

 

ということで、Retty社のこの設計は現時点で間違いではないものの、マイクロサービスアキーキテクチャー信者にとっては悪夢であり、「あわわ・・」となっているんじゃないかなあと思い取り上げさせていただきました。