Help us understand the problem. What is going on with this article?

[翻訳][ネタ] これが未来だ!(It's The Future)

More than 1 year has passed since last update.

原文:https://circleci.com/blog/its-the-future/

ヘイ、ボスが君と話せっていうんだ。Webアプリに詳しいんだろ?

ああ、俺はもうわりと分散システムガイだぜ。ContainerCampとGlueonから帰ってきたばっかりで、来週はDockerconに行くんだ。業界が進歩するのを目の当たりにしてワクワクしている。全てがシンプルになって信頼性が高まるんだ。これが未来さ!

すごいね。僕は今シンプルなWebアプリを作ろうとしてるんだ。Railsの普通のCRUDアプリで、Herokuにデプロイしようと思ってる。今後もこの方法でよさそうかい?

オー、ノー。それは古いやり方だ。Herokuは終わった。もう誰も使っていない。今はDockerを使う必要がある。それが未来だ。

OK、それは何だい?

Dockerは新しいコンテナリゼーションの手法さ。LXCみたいなもので、パッケージングフォーマットでもあり分散プラットフォームでもあり、分散システムをごく簡単に作るためのツールでもある。

コンテナリ…なんだそりゃ?LXEって?

LXCだ。chrootの強化版みたいなもんだ。

チェ…ルート?

OK。Docker、コンテナリゼーション。これが未来だ。仮想化みたいなもんだが、もっと速くて安価なんだ。

ああ、じゃあVagrantみたいなものか。

ノー。Vagrantはもう終わった。これからは全部コンテナライズされる。それが未来だ。

そうか、じゃあもう仮想化については知らなくていいんだな?

ノー。仮想化については知る必要がある。なぜならコンテナのセキュリティは完璧ではないからだ。だからマルチテナント環境で何かを実行したければサンドボックスから抜け出せないようにする必要がある。

OK、ちょっとわからなくなってきた。話を戻そう。コンテナという仮想化のようなものがある。で、これはHerokuで使えるんだな?

うーん、Herokuはいくらかdockerをサポートしている。しかし言っただろ、Herokuはもう終わりだ。コンテナをCoreOS上で動かすんだ。

OK、そりゃなんだ?

Dockerといっしょに使うためのクールなホストOSさ。いや、Dockerすら必要ないんだ。rktを使える。

ロケット?

ノー、rkt。

分かった、ロケット。

ノー、今はrktと呼ばれているんだ。全然違う。rktは別のコンテナリゼーションフォーマットで、Dockerほど一つにまとまっていないんだ。だからもっとコンポーザブルだ。

それはいいことなのか?

もちろんだ。コンポーザビリティこそ未来だ。

OK。どうやって使うんだ?

分からない。誰も使っていないと思う。

ハァ…。CoreOSについて何か言ってたな?

ああ、だからCoreOSはDockerといっしょに使うホストOSだ。

ホストOSって?

ホストOSはコンテナを動かすためのものだ。

コンテナ?

そう、コンテナの中で何かを動かすんだ。EC2インスタンスか何かをセットアップする。その中にCoreOSを入れる、そしてDockerデーモンを動かし、Dockerイメージをその中にデプロイするんだ。

それのどの部分がコンテナなんだ?

全部だ。君のアプリがあるとする。Dockerfileを書く、それをローカルでイメージにする。そしてDockerホストにpushするんだ。

ああ、Herokuみたいに?

ノー、Herokuじゃない。言っただろ。Herokuはもう終わった。今はDockerを使って自分のクラウドを動かすんだ。

何?

すごく簡単だ。#gifeeを見てみろ。

ジフィー?

「Google’s infrastructure for everyone else」の略だ。ツールボックスから何かを取り出して、コンテナを使って、Googleと同じインフラが手に入るんだ。

単にGoogleのものを使うだけじゃだめなのか?

6ヶ月後にそれができると思うか?

OK。誰かがそれをホスティングしているわけじゃないんだな?僕は自分のアプリを自分でホスティングしたくないな。

うーん、AmazonにECSがある。でもXMLみたいなクソを書かなけりゃならないぞ。

OpenStackはどうだ?

うげぇ。

うげぇ?

うげぇだ。

わかるだろ、自分でホスティングしたくないんだよ。

いや、それは実に簡単だ。Kubernetesのクラスタをセットアップすればいい。

クラスタが必要なのか?

Kubernetesクラスタだ。君の全てのサービスのデプロイを管理してくれる。

僕は1個しかサービスを持ってないよ。

どういう意味だ?アプリがあるんだろ?それなら少なくとも8個から12個のサービスがあるはずだ。

なんだって?いや、1個だけだ。サービスがどんな意味であれ、1個だけだ。

ノー。マイクロサービスについて調べてみろ。未来だ。今はみんなそうやっている。君のモノリシックなアプリを12個のマイクロサービスに分割しろ。1個のジョブにつき1個のサービスだ。

それはやりすぎじゃないか。

それが信頼性を高める唯一の方法だ。認証サービスがダウンしたとしよう…

認証サービス?前に何度か使ったことがあるこのgemを使おうとしていたんだが。

よろしい。gemを使え。それをプロジェクトに入れる。RESTful APIを作る。そうすれば他のサービスがそのAPIを使えるようになる。そして安全にエラーをハンドルできるようになる。それをコンテナに入れて継続的にデリバリーするんだ。

OK。するとバラバラな10数個のサービスができるわけだ。次はどうする?

そう、Kubernetesの話をしていたんだった。Kubernetesが君のサービス群をオーケストレートしてくれる。

オーケストレート?

そうだ。君にはサービスがあって、それを信頼可能なものにしなければならない。だからサービスのコピーが複数必要だ。Kubernetesは十分な数のコピーを作って、君のフリート(サーバ群)の複数のホストに分散させてくれる。それでいつもavailableになる。

今度はフリートが必要なのか?

ああ、信頼性のためだ。しかしKubernetesが君に代わりに管理してくれる。Kubernetesが役に立つことは君も知ってるだろ。Googleが作ってetcd上で動かしてるんだ。

etcdって?

RAFTの実装の一種だ。

OK、Raftって?

Paxosみたいなものだ。

神よ、このくそったれなウサギ穴はどこまで続くんだ?僕はアプリを1個起動したいだけなんだ。ハァ、クソ。OK、深呼吸だ。ジーザス。OK、Paxosってなんだ?

Paxosは70年代の古い分散型コンセンサスアルゴリズムみたいなもんで誰も理解してないし使ってもいない。

素晴らしい。いい情報をありがとう。で、Raftってのは?

誰もPaxosを理解していないんで、ディエゴってやつが…

お、そいつと知り合いなのか?

いや、彼はCoreOSで働いている。ともかく、ディエゴが博士論文のためにRaftを作ったんだ。Paxosは難しすぎるからってな。ムチャクチャ頭いいやつだぜ。で、実装としてetcdを作った。でAphyrがそれを良いと言った。

Aphyrってなんだ?

Aphyrは「Call Me Maybe」を書いたやつだ。ほら、あの分散システムとBDSMの人だよ。

BDSMだって?

そう、BDSM。サンフランシスコだからな。みんな分散システムとBDSMに夢中だ。

うーん、わかった。でそいつがそのKaty Perryの歌を書いたんだな?

いや、彼はどのデータベースもCAPを満たしていないという一連のブログを書いたんだ。

CAPって?

CAP定理。一貫性 (Consistency)、可用性 (Availability)、分断耐性 (Partition-tolerance)の3つを同時に満たすことはできないという定理だ。

OK、DBはどれもCAPを満たしていないって?それにどんな意味が?

DBはどれもクソってことだ。Mongoみたいにな。

Mongoはスケーラビリティが高いと思っていたが。

他のみんなは思ってないよ。

OK、それでetcdは?

ああ、etcdは分散キーバリューストアだ。

ああ、Redisみたいなもんか。

ノー、Redisとは全然違う。etcdは分散している。ネットワークがパーティションされているとRedisは書き込んだことの半分を失う。

OK、それは「分散」キーバリューストアなんだな。それがどう役に立つんだ?

Kubernetesはetcdをメッセージバスとして使い、標準的な5ノードのクラスタをセットアップする。Kubernetes自身のサービスのいくつかと組み合わさって、かなり弾力性のあるオーケストレーションシステムを提供する。

5ノード?僕は1個のアプリしか持ってないよ。それを実現するためにいくつのマシンが必要なんだ?

んー、君が必要とするのは12個のサービス、そして当然それらを冗長化するためのコピー、ロードバランサをいくつか、etcdクラスタ、データベース、kubernetesクラスタ。そう、だから50個くらいコンテナが必要かな。

そんなバカな!

大したことじゃない。コンテナは実に効率的だから、それを8個のマシンに分散できるはずだ。すごいだろ?

そうかもしれない。で、そうすれば普通に僕のアプリをデプロイできるんだな?

もちろんだ。ストレージはまだDockerとKubernetesの未解決の問題で、ネットワークにも多少の手間はかかるが、基本的にはできるよ。

なるほど、OK。分かってきた気がする。

すばらしい!

ご説明をありがとう。

いえいえ。

自分が理解できているか確認させてくれ。

もちろんだ!

つまり、僕はシンプルなCRUDアプリを12個のマイクロサービスに分割し、それぞれにAPIを実装して他のAPIを呼ばせる。エラーはしっかり制御する。それをDockerコンテナに入れて、8個のマシンのフリートを起動する。それらはCoreOSが動いているDockerホストで、etcdによる小さなKubernetesクラスタを使ってオーケストレートする。ネットワークとストレージの「未解決問題」を解き明かして各マイクロサービスの冗長コピーをフリートに継続的にデリバリーする。合ってるかい?

そうだ!素晴らしいだろ?

僕はHerokuに帰るよ。


この原文に触発されたJavaScript版もあります。
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.tfs5s4ozw

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away