読者です 読者をやめる 読者になる 読者になる

レガシー分散システムからモダン分散システムへ

docker architecture 分散

はじめに

Dockerは個人的には色々便利なんだけど、オンプレな本番環境に適用するメリットあるかな? とたまに思います。 Infrastructure as Codeは別な方法でも実現できますし。

Googleとかもコンテナは分散システムの基盤としてを重要視してるように感じるので、本番環境に適用する決め手はこっちかな、と思っています。

なので、今回は思考の整理に、近代的な分散システムってなんで要るんだっけ? というのをまとめてみました。

分散システムとは?

分散システムと聞くと何を思い浮かべますか? SparkやHadoopですか? それともUnixダウンサイジングですか?

この記事を見る人の多くは前者を思い浮かべると思うのですが、Wikipedia的には後者の意味で記載されています。

分散システム - Wikipedia

前者は分散コンピューティングとして扱われてますね。英語でも同じかどうかは調べてないですが。

エンタープライズ系の人だと後者もなじみ深いと思うのですが、ようはメインフレームの対義語です。 単一のマシンですべての業務をこなすメインフレームに対して、複数のマシンでそれぞれの業務をこなすのがレガシーな意味での分散システムですね。 つまり、現在私たちが触るほとんどのシステムは「分散システム」となります。このような業務(アプリ)毎に専用のマシンを使うアプローチを「レガシー分散システム」と呼びましょう。

対して、SparkやHadoopのような巨大なワークロードを複数のマシンで分散して実行するアプローチや、 docker-swarmやk8sやmesosのような多様なワークロードを複数のマシンで分散して実行するようなアプローチも分散システムと呼ぶこともあると思います。 このような複数のコンピューターリソースを束ね、業務(アプリ)毎に振り分けるアプローチを「モダン分散システム」と呼ぶことにします。 ちなみに、巨大なワークロードも究極的には多様なワークロードの一種でしかないので、今回は分散コンピューティングの話はあまりしません。

最近、Dockerをはじめとして「コンテナ!」「コンテナ!」と言っていますが、開発環境と本番環境をポータブルに行き来できる、ということ以外には「モダン分散システム」の作りやすさがあります。 必要なCPU数やメモリをコンテナに割り当てて、それを実行するのに必要なリソースをスケジューラで確保して、実体はプールしたマシンのどこかしますがあたかも単一のOS上で動いてるように見せかけます。 GoogleのBorgやKubernetes、Apache MesosApache Hadoop YARNはそのためのミドルウェアですし、IntelのRack-Scale-Design(旧Rack-Scale-Architecture)はそれを想定したハードウェアです。

なぜモダン分散システムが必要か?

なぜ、このような仕組みが必要になってきたかというと、CPUが十二分に速くなってきた事とCPUがこれ以上はあまり速くならない事です。

20年前、10年前にくらべてCPUはずいぶん速くなりました。1つのアプリケーションを走らせただけで通常はCPUが100%になることなどなく、ユーザからのリクエストや処理するデータがCPUに対して少なくてほとんど遊んでるマシンも珍しくありません。

また、フリーランチは終了しました。ムーアの法則は破れこれ以上CPUは単独では速くならないとも言われています。そのため、最近は1ソケットだろうとサーバ買えば少なくとも4コアは付いています。

シングルスレッドのアプリケーションだとOSが賢くスケジューリングしてくれるにしても効率的に稼働させるのは限度があります。

スマートな相乗り

こうした無駄なリソースを効率的に使うための方法があります。それは「相乗り」です。 1つのマシンで複数のアプリケーションを動かすことでサーバの利用効率を高め、マシン導入の手間も省く事ができるのでビジネス的にも大きなメリットがあります。

が、メリットがあるので使われてきましたが、相乗りは蛇蝎のごとく嫌われていました。曰く「片方のアプリケーションがリソースを使いすぎてもう片方も重くなる」「ポートが被る」「ファイルパスが被る」と運用上のリスクがたくさんあるからです。

これはすべて真実です。わたしも下記で書いてあるような作りこみをしない限りは「相乗り、ダメ、ゼッタイ」というスタンスです。

ただ、これは相乗りが悪いのじゃなくて、リソースが分離されてないからです。

例えば、ファイルパスやポートはjailでもかなりの部分綺麗に分離できます。テスト環境のような計算リソースの共有が許容されるレベルならこれで十分でしょう。

また、Dockerでも使われているcgroupsを使えばCPUやメモリも適切に隔離することができます。このような「スマートな相乗り」であれば、サーバリソースを効率的に使うための優れた方式です。

近年、vmwareとかの仮想化が流行っているのもこの「スマートな相乗り」を実現するための手法の一種だからです。

ワークロードの分散

一方で、これはまだ不十分です。アプリケーションで必要なリソースとタイミングはそれぞれ異なります。

CPUが2個ついたマシンが2台あったとして、何時にどのサーバでどのアプリケーションを動かすのが最適になるのかをJP1とかでスケジューリングできますか?

そういったことを考慮してジョブの依存を書くのは至難の業です。しかも、日によってワークロードが変わるかもしれません。

ひょっとすると今日はいつもよりサーバAで動かすジョブのデータが多くて、他のジョブはサーバBで動かしたほうが効率的かもしれません

ダイナミックな情報も必要なので、どのサーバで動かすのが適切かを人間が決めることは出来ません。なのでプーリングとスケジューラが必要です。

レガシー分散システムのように「業務Aを実行するサーバ」、あるいはそれに相乗りの要素を加えて「業務AとBを実行するサーバ」という概念を捨てます。

そうではなく「業務を実行するコンピュータリソースのプール」として管理します。例えば合計4個のvCPUプールとか。

あとは簡単ですね? vCPUの空き状況を見ながらタスクを振ればワークロードは分散されます。

こうすることで、サーバの使用率を最大化することが出来ます。これはサーバ費用と調達時間という2つのコストを削減できるのでビジネス的にもとても良いことです。

vmwareのような仮想化技術では「スマートな相乗り」までは実現できますが、仮想OSで動いてるシステムがレガシー分散システムだとワークロードの分散は出来ません。

でも、相乗りなんでしょ?

メリットは確かにありますが「相乗り」というリスクを犯してまで使うべきでしょうか?

もちろん「スマートな相乗り」であれば基本的に相乗りのデメリットは受けないのですが、そのスマートさを保証する機能自体のバグというリスクはあります。

私は使うべきだと思います。なぜなら、本質的にモダン分散システムは冗長構成だから。

1台のマシンで100個のリクエストを捌く構成より、10台のマシンで10リクエスト捌く方が機器障害やメンテナンス時のインパクトが小さいです。 まあ、これは前提として1台のハイスペックマシンだと意味がないので、ある程度ホストマシンも数をそろえておく必要はあるけど。

ダン分散システムへの移行は必須か?

ダン分散システムはサーバーの使用率を最大化することで、総体としてのサーバ費用と業務毎における調達時間を圧縮できるので、ビジネスメリットがあります。

でも、それだけなら移行する動機付けとしては弱くもあります。

まず、調達時間の圧縮は仮想で十分。サーバ費用に関しても仮想ならある程度割り当てるリソースの調整でベアメタルよりはマシになります。

なので、これが決定的な導入理由にはならないことも多そう。

ハードウェア費用ケチるより、利益を上げる作業をした方が儲かるビジネスモデルもあるしね。人のリソースは有限だから。

どちらかというと、Elasticにリソースをアプリケーションに割り当てれる運用性が価値になるかな。仮想だとOSの起動や停止から始まるのでトロいし。 この特性はバッチサーバ、特に並列処理とかに有用になりそう。SparkとDockerを同じリソーススケジューラで管理するとかが決め手かも。

あとは、昼と夜でリアルタイムとバッチ処理のワークロードが逆転するとかのケースにも使いやすいかな。これもOSの上げ下げとかしてると面倒だし。

運用面でも、OS単位じゃなくてアプリケーション単位でリソースがモニタリングしやすくなるので、慣れると楽そう。

いずれにしても、「移行」という観点では「今すぐ移行するべき!」と強い言葉を使うほどじゃないかな? はまりそうなユースケースでは使うべきだし、ゼロから設計するなら構築したいけど。

あと、当然だけどサーバーが大量にあってコストを圧迫してるなら検討するべき。

どちらかというと、こういうモダンなシステムを導入するにあたっての、運用や構成の見直しが一番のメリットになるといういつものパターンな気もする。

マイクロサービスとかCDとかもそうだけど、実現しようとするといろんな要素をクリアしなくちゃいけなくて、結果として前提条件をクリアすることで効果が出るというパターン。。。

まとめ

最近、もやもやっとすることをとりあえず文章にして形にしてみました。突込みや指摘をお待ちしております。

移行は必須か? のところが相当整理されてない感じがにじみ出てますが、実際どうだろうなー、というのが正直なところ。 まあ、結論が出せる程理解してないからこんな記事書いてるのだし。

ちなみにクラウドベンダーやGoogleのような巨大インフラを持ってる会社は 運用してるサーバの数が馬鹿にならないだろうから、こういうのに積極的なのだと思う。

参考