Codeは別な方法でも実現できますし。Googleとかもコンテナは分散システムの基盤としてを重要視してるように感じるので、本番環境に適用する決め手はこっちかな、と思っています。いうのをまとめてみました。それともUnixやダウンサイジングですか?この記事を見る人の多くは前者を思い浮かべると思うのですが、Wikipedia的には後者の意味で記載されています。Wikipedia前者は分散コンピューティングとして扱われてますね。英語でも同じかどうかは調べてないですが。エンタープライズ系の人だと後者もなじみ深いと思うのですが、ようはメインフレームの対義語です。単一のマシンですべての業務をこなすメインフレームに対して、複数のマシンでそれぞれの業務をこなすのがレガシーな意味での分散システムですね。現在私たちが触るほとんどのシステムは「分散システム」となります。このような業務(アプリ)毎に専用のマシンを使うアプローチを「レガシー分散システム」と呼びましょう。docker-swarmやk8sやmesosのような多様なワークロードを複数のマシンで分散して実行するようなアプローチも分散システムと呼ぶこともあると思います。このような複数のコンピューターリソースを束ね、業務(アプリ)毎に振り分けるアプローチを「モダン分散システム」と呼ぶことにします。ちなみに、巨大なワークロードも究極的には多様なワークロードの一種でしかないので、今回は分散コンピューティングの話はあまりしません。最近、Dockerをはじめとして「コンテナ!」「コンテナ!」と言っていますが、開発環境と本番環境をポータブルに行き来できる、ということ以外には「モダン分散システム」の作りやすさがあります。必要なCPU数やメモリをコンテナに割り当てて、それを実行するのに必要なリソースをスケジューラで確保して、実体はプールしたマシンのどこかしますがあたかも単一のOS上で動いてるように見せかけます。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とかもそうだけど、実現しようとするといろんな要素をクリアしなくちゃいけなくて、結果として前提条件をクリアすることで効果が出るというパターン。まとめ最近、もやもやっとすることをとりあえず文章にして形にしてみました。突込みや指摘をお待ちしております。ところが相当整理されてない感じがにじみ出てますが、実際どうだろうなー、というのが正直なところ。結論が出せる程理解してないからこんな記事書いてるのだし。運用してるサーバの数が馬鹿にならないだろうから、こういうのに積極的なのだと思う。(7)月別アーカイブはてなブログをはじめよう!pascal256さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。