Kubernetes VS Barcelona

はじめに

Kubernetes というのが流行ってるみたいなので、Cloud Native DevOps with Kubernetes [Book] という本をちょっと読んでたら、驚くような話が書いてありました。

Distributed systems engineer and writer Cindy Sridharan has estimated that it takes around a million dollars in engineer salary to get Kubernetes up and running in a production configuration from scratch

「Kubernetesを自社で立ち上げようと思うなら、技術者に100万ドル給料を払う用意しとけ」と言っているのです。

これは、self hostingを前提とした見積もりで、実際その後には、「現実的な方法は、AmazonのEKSやGoogleのGKSなどのマネージドサービスを使うことです」という話が続くのですが、Kubernetesが複雑で大規模なシステムであり、運用に大きな負担がかかるということは間違いないと思います。

これを読んで、私は「えええええっ！、俺たちそんなにもらってないよ」と思ってしまいました。

何を言ってるかというと、デジカではBarcelonaっていう、Kubernetesと似たようなシステムを自社開発しているんですが、それを使ってインフラ一式を二人だけで運用しているんですね。self hostingどころか、ツールそのものの開発をした上で、二人で全部面倒見てるんだから、だいぶ安上がりじゃないかな、って思ったんです。

二人というのは、Barcelonaの開発者である@k2nrと私(@essa)です。Barcelonaはオープンソースとして公開していますが、実際使っているのはおそらくデジカだけなので、私は今の所、世界で唯一のBarcelonaのユーザということになります。日頃使っていて、これはよくできるなと毎日のように実感してはいたのですが、見方によってはこれは100万ドルの価値があるのかなあ、とか思ってしまいました。

「Kubernetesと似たようなシステムを自社開発」というのはもちろん言い過ぎなんですが、開発チームのメンバーが10人から20人くらいの規模であれば、そんなに使い勝手に違いはないと思います。特に、運用で使うツールだと、ツールが想定しているシステムの規模と、自分たちが運用しているシステムの規模が一致していることは重要です。私には、Kubernetesは明らかにに超大規模なシステムに最適化されていて、インフラ専任の人が何十人もいるような組織で使うものではないかと思えます。

Kubernetesを検討している人たちに、「Barcelonaっていうのもあるよ。ちょっと見てみて！」と言いたくなりました。

そこで、これから、Barcelonaの紹介記事兼チュートリアルをシリーズで描いてみようと思います。

• Kubernetes VS Barcelona（この記事）
• Barcelonaのアーキテクチャ
• Barcelonaチュートリアル1（ローカルDBでまず使ってみる）
• Barcelonaチュートリアル2（運用編）
• Barcelonaチュートリアル3（AWSにインストール）
• Barcelonaチュートリアル4 (Mastodonを動かす)
• Barcelonaの今後

この記事は、シリーズの一つ目で、Kubernetesと比較しながら、Barcelonaがどういうところが良くて、なぜ私がお勧めしようと思っているかについて描いてみます。

PaaS革命としてのDocker

まず、アプリケーション開発者から見ると、Barcelonaというのは、PaaSに近いと思います。「Dockerイメージさえ作れば、あとは、なんだかわからんけど Barcelona がうまくやってくれる」というイメージ。

この点では、Kubernetesも似ていると思います。

インフラ担当が「ここから後は俺たちにまかせろ！」と言い切るためのツール。

Dockerの功績は何よりこれだと思います。

Dockerができるまでは「ここから後はまかせろ」の「ここ」が明確ではなかった。たとえばPaaSが「普通のRailsアプリならたいていそのまま動きます」と言って、確かにそうなんだけど、いざやってみるとあれが動かないなんてケースはよくあります。「普通のRailsアプリ」がなんなのか、おおよその範囲は合意があるんですが、その境界線をきっちり引くのはなかなか難しいものです。

Dockerができたことで、アプリ担当とインフラ担当の境界線がはっきりしました。「Dockerイメージの中」はアプリ担当が好きにやっていい領域です。何のパッケージを入れても何のライブラリを入れても削っても言語処理系のバージョンを上げても下げてもかまわない。

とにかく、Dockerイメージさえできれば「あとはまかせておけ！」と自信を持って言い切れるようになった。

これが開発速度に与える影響は大きい。稀にしかなくても境界線上でのトラブルの可能性があると、どうしてもスケジュールを同期したくなって、Deployするときは、両者顔を付き合わせてやりましょう、という話になってしまいます。アプリ担当とインフラ担当がそれぞれ勝手に非同期で仕事を進められれば、かなりスピードが上がります。

インフラ担当の仕事が明確なったことで、それをサポートするツールも作りやすくなって、いろいろできましたが、結局標準として残りそうなのが、 Kubernetes ということだと思います。

PaaSビルダー

DockerによってPaaS的なものが作りやすくなると、やっぱり自前のPaaSを持ちたくなります。

特に、本番環境として使うには、どうしてもアリモノではかゆいところに手が届かない。

アプリ開発者にはPaaS的に見えて、勝手にどんどん進めらるけど、いざという時には中が見えて、好きに手を入れたい。そういうのが作りたくなります。

Barcelonaの開発動機はまさにそれです。Kubernetesもある一面は同じだと思います。自分専用のPaaSを作るツール。実際、デジカでは、プロダクション用に3つ、ステージングテスト用に2つ、それぞれ微妙に違う計5つの社内むけPaaSを運用しています。

インフラ的には、アプリケーションごとに性能やセキュリティに関する要件が違うので、分けたいんですね。特にデジカでは決済サービス用のアプリがあって、これはセキュリティが特に重要なので、このアプリと他のアプリを同じ所に置きたくない。そういう意味で自前のPaaSを作れるというのはありがたい。

だから、Dockerが普及したことで、KubernetesやBarcelonaのようなものが作られるようになったのは、ある意味、必然の流れだと思います。

Orchestration Tool

ただ、Kubernetesは、PaaSビルダーとは呼ばれなくて、”Orchesration Tool” と呼ばれています。

これは、Dockerの使われ方が、微妙に変わってきたことと関係あると思います。最初のうちは、一つのDockerコンテナに複数のプロセス、複数のサービスを詰め込むような使い方が多かったんです。でも、これが広まるにつれて、単機能、単一プロセスのコンテナを多数組み合わせて使うことが一般的になりました。

また、アプリケーションの作り方としても、モノリスからマイクロサービスということで、一つのサービスを単機能の小さなアプリケーションに分割して、それらが協調して動くような形態が Good Practice とされるようになってきました。

こうなってくると、「あとはまかせとけ！」と言った後の、Dockerイメージができてから後の仕事が、思ったより大変になります。

そこで、そのインフラ担当の仕事を支援するためのツールが必要とされてきて、それらが Orchestration Toolと呼ばれるようになったのでしょう。

私は、Sensuという監視システムをBarcelonaで動かしていますが、これは主要な機能を複数のプロセスに分割した典型的なマイクロサービス構成のアプリケーションです。それを機能別の複数のコンテナとしてBarcelonaの中で組み合わせて動かすことも問題なくできたので、Barcelonaも同じように Orchestration Tool という側面を持っていると思います。

だから、次のような点で、BarcelonaとKubernetesは似たようなツールであると言えるでしょう。

• Dockerイメージを本番環境で動かすための「場」を用意するツール
• 本番運用に伴うさまざまな要件を統合的に支援するツール
• マイクロサービスを構成する複数のDockerコンテナを協調して動かすツール

インフラ側からの視点

このように、Barcelonaは、基本的な目的や機能は Kubernetesと近いのですが、設計方針は対極的と言っていいくらい違います。

• Kubernetesはさまざまな環境に対応しているが、BarcelonaはAWS専用
• Kubernetesは全部自前でやろうとするが、Barcelonaは、AWSの各種マネージドサービスを使う形で機能を実現する
• Kubernetesはさまざまなオプションをサポートするが、Barcelonaは Good Practice を強制する
• Kubernetesは数万コンテナの規模まで想定しているが、Barcelonaは数十から数百コンテナレベル

その結果、インフラ担当の視点からは見え方が全然違ってきます。

• Kubernetesは勉強してから使わなきゃいけないもの
  • Kubernetes自体の事前勉強
  • それをのせるクラウド（AWS,GCP,Azure）全般の勉強
• Barcelonaは勉強しながら使えるもの
  • Barcelonaをなんとなく動かしながらAWSを勉強することができる

これが、今回、Barcelonaをアピールしようと思った一番大きな理由です。

本来は、なんでもちゃんとマスターしてから使うべきです。でも今時、それができる人員、組織、環境、スケジュールがある方が稀でしょう。走りながら覚えることをしたことがないエンジニアなんていないと思います。

特に、クラウドのことを学校でちゃんと勉強してから実戦投入されるなんてまずない。おそらく、アプリを作る方が優先で、開発者の中でちょっと詳しそうな人が無理やりインフラやらされてしまうことが多いでしょう（体験談ではありません（笑））

そういう人にとって、Barcelonaこそが福音であると、私は声を大にして言いたい！

たとえば、最初のPaaSっぽいものを作る時、コンテナを走らせるノードインスタンスをどういう風に配置するか、Kubernetesは「どうにでもできるからあなたの好きなようにやってよ」と言う。Barcelonaは「普通、AWSではこうやるんだよ、他にオプションはないけど、どうせあんたにゃオプションがあっても正しく選べない。だから、悪いことは言わないから私の言う通りにしなさい」と言う。

それで、bcn district createというコマンド一つ打って、黙って見てると、次のようなものがずんずん作られていきます。 （チュートリアルのとおりやれば自分で動かして確認できます）

• VPC
• Public Subnet X 2
• Private Subnet X 2
• Nat Gateway
• ECS Cluster
• S3 Bucket (ECS制御情報格納用)
• コンテナインスタンス用のASG (AutoScalingGroup)

なんで、Subnetが二つずつあるかと言えば、複数のAvailability Zone(データセンター)にまたがってリソースを配置した方が、万が一のデータセンター単位の障害があった時に、復旧が全然早いからです。インスタンスは、ASGの配下で起動するので、そういうレベルの障害でも自動的に復旧するようになっています。

AWSを長く使っていれば常識でもありますが、最初はそんなこと思いつかないでしょう。こういうことは、勝手にやってくれた方がいいと思います。

実は、Barcelonaを開発したもう一つの動機は、PCIDSSに合格するためです。

PCIDSSはクレジットカードを扱うシステムのための監査基準で、内容は運用体制など人的な要件もたくさんありますが、コンピュータシステムやネットワークに関する要件もあります。これに合格するようにインフラを一新しなくちゃいけないので、そのために作りました。実際、これでPCIDSSに合格しました。

Private Subnetがあるのは、PCIDSSの一つの要件で、サーバは外部（インターネット）に直結したネットワークに配置してはいけないとされています。

だから、Barcelonaが強制する Good Practiceとは、一つは「PCIDSSに合格できるレベルのセキュアな構成」ということです。これだけで合格するとは言えないけど、少なくとも、PCIDSSの障害になるようなことはありません。

もちろん、このレベルを自力で楽々クリアできる人ならば、「やっぱり吊るしはいやだ。オーダーメイドで好きにやりたい」と思うでしょうから、Kubernetesを使った方がいいと思います。

そうでない人にとっては、自動的に構築してくれる上に、それが生きた教材となっているということです。

BarcelonaがAWS basedであることの意味

Kubernetesが自前でやることを、Barcelonaは AWSのマネージドサービスを使ってやる、この違いは、「Desired State Management」の実装方法にもあります。

「Desired State Management」は「宣言的インフラ構築」とも言えるかもしれませんが、次の動画で説明されています。

料理にたとえると、料理の手順を時系列に沿って指示したレシピを渡すのではなく、メニューの写真のような出来上がりのイメージを渡すと、それを作ってくれるシェフのようなものです。

これは非常に重要なことで、たとえば、「このアプリケーションを多重度3で動かしてくれ」と言えば、その時、2つしか動いてなければもう一つ立ち上げるし、すでに3つ動いていれば何もしない、4つ動いていれば一つ止めると言う動作を勝手にやってくれるわけです。

自分で今いくつ動いているか確認した上で、状況に応じて、あるときは起動コマンドを打つ、ある時は終了コマンドを打つ、と言うような、判断をしなくていいわけです。

これは、ツールの利用者にとっては嬉しい機能ですが、ツールを作る側から見るとなかなか大変です。”Desired State”と対象リソースの関連は、さまざまな理由で動的に変化するので、網羅的な動作確認が難しく、エッジケースのバグはなかなか無くなりません。しかし、これは運用の根幹でもあるので、非常に高い信頼性を求められます。

Barcelonaの一番良いところは「デジカごときにそんなたいそうなものを作れるわけがない！」と言う見切りが徹底していることです。

Barcelonaも「Desired State Management」を実装していますが、そういうクリティカルなところは、全部、CloudFormationなどのAWSの標準サービスに任せています。

たとえば、コンテナの多重度管理は、ECSにまかせています。ホストインスタンス（Node）の多重度管理はASG(AutoScalingGroup)にまかせています。これにより、以下のようなメリットがあります。

• Barcelona自体の信頼性は運用に影響しない、AWSの信頼性に依存する
• 状態を把握したり監視したりするのに、CloudWatchやAWS Web Consoleなどの標準のツールが使える
• 細かい調整をするために、AWSのドキュメントだけを見ればよい

Kubernetesも、最終的にはAWSのサービスに依存する部分もあるかと思いますが、マルチクラウド対応の抽象化層を通しての関係になるので、どうしても、Kubernetes独自の概念を理解した上で、それを通してみることになります。もし、Kubernetesの導入支援ツールを使っていたら、そこにもう一つ支援ツールのレイヤーが重なるので、それぞれのレイヤーを翻訳しながら考えるのは大変だと思います。

通常運用時には、Kubernetesだけを見ていればよくて、AWSにはタッチしなくていいかもしれませんが、トラブル時にはそうはいかず、AWSのツールを見たり、それで操作することになります。その場合、抽象化層がある分だけ、運用担当の負荷は高くなります。

これは専任が少ない（いない）小規模なチーム向けのツールとしては、非常に重要な設計方針だと思います。

別の例をあげると、ノードインスタンスにOSレベルの脆弱性があって、これを入れ替える時、Barcelonaでは、AMIのIDを入れ替えた上で、bcn applyというコマンドを打つだけです。つまり「このクラスタのノードインスタンスのAMIはこれこれである」という宣言をするのですね。

そうすると、手続き的には、次のようなことが自動的に行われます。

• 新しいAMIのインスタンスを起動する
• 古いインスタンスを全部Drain状態にする
  • このインスタンスで新しいコンテナは起動しなくなる
  • このインスタンスで現在動いているコンテナを他のインスタンスで起動する
  • 代わりのコンテナが起動したら、古いコンテナを停止する
• Drain状態のインスタンスが空になったらこれを停止する
• 古いAMIのインスタンスがなくなるまでこれを繰り返す

つまり、稼働中のサービスに影響がないようにして、うまいこと入れ替えをしてくれるんです。最初見たときに、「すげーことやるな、でも途中でトラブっても大丈夫？」と思いました。こういうのは、途中で問題が起きなければ単純な処理ですが、この入れ替えの最中に一部のコンテナやインスタンスが異常停止すると、ややこしいことになります。

そしたら、これそのものはほぼ、ECSとASGが持っている機能なんですね。ただ、Lifecycle hook という機能を使っていて、そこだけは Barcelonaが自動的に処理してくれます。

ここだけは、目を皿のようにして自分で確認しましたが、あとは「天下のアマゾンさんだから、まあ大丈夫だろ」っていう感じで、それを使っています。

Barcelonaのようなものを使うということは、運用の中でものすごいクリティカルな部分をそこにあずける感じで、普通はまともな決断とは言えないのですが、このように、本当にクリティカルなところはだいたい、十分な実績がある既存のサービスに依頼する形で実装されているので、そんなに心配するところはないんですね。

「お前は本当に信頼できるヤツなのか」と問い詰めると、Barcelonaはすっと身をかわして、気がつくとそこに立っているのはAWSで「俺が信頼できないなら、お前は誰を信頼できると言うのだ」と逆ギレしてきた、みたいな感じです。

そういう変り身の術のような形で「Desired State Management」が実装されています。

Barcelonaの課題

現在のところ、Barcelonaを使っているのは（おそらく）デジカ一社ですが、デジカでは2年間ほぼ全てのサービスをこれで運用しているので、実績は十分あります。十分に本番運用に耐えるものであると自信を持って言えるのですが、もちろん課題はいくつかあります。

• ドキュメント不足
• リリースマネジメントがない
• インストールが難しい
• セキュリティ重視の反面、コストとスケーラビリティについては甘いかも

特に、インストールは大変です。

Barcelonaの本体は、APIを提供するプロセスなのですが、これもをBarcelonaクラスタの中で動かします。この形態によって、AWSの各種サービスを活用して、信頼性のあるプロセスとして運用できるわけですが、段階的なインストールができません。

最初のインストールで、4つのサブネットを持つVPCを作成し、その中で、Barcelona APIのプロセスを動かさないと、その後のことが何もできません。

これを支援するインストーラスクリプトは用意されているのですが、これが行うことがあまりにも多く、説明が十分ではないと思います。また、当然ながら、デジカでは、最初にこれを実行してインストールした後は、そのクラスタをそのまま使っていますので、十分検証されているとは言えません。

そこで、これから、このブログでいくつかのチュートリアル記事を書いて、もっと気軽に Barcelona をインストールして試せるようにしていきたいと思っています。

それと、決済事業が主たるターゲットということは、セキュリティに対する要求が厳しい反面、スケーラビリティとコストに関しては、一般的なWebシステムより要求水準が低いと言えるかもしれません。決済システムでは、一つのリクエストの処理が重い分だけ、大規模なスパイクに対応したり、コストを最適化するために細かく稼働インスタンス数を調整するような必要は少ないと思います。

ただ、Barcelonaは、CloudFormationを通して構成を作るアーキテクチャーとなっていますので、AWS(CloudFormation)が対応できる範囲であれば、今後、機能を拡張するのは容易です。ECSは、現在もアグレッシブな開発が継続していて、続々と新機能がリリースされていますので、Barcelonaも今後、機能強化して、ECSの機能をフル活用できるようにしていきたいと思います。

まとめ

Kubernetesと比較しながら、Barcelonaの特色をまとめてみました。

Barcelonaとは、次のようないくつかの顔を持つ、オープンソースの運用支援ツールです。

• アプリケーション開発者とインフラ担当の作業分担を明確化し共同作業を支援する「PaaSビルダー」
• 必要最小限だがフルセットの機能を持つ 「Orchestration Tool」
• AWS活用の Good Practice を集めた、「動くAWSの教科書」

これを使うことで、AWS上でのシステム構築、運用の人的コストを飛躍的に下げ、セキュアで信頼性の高い運用を行うことができます。

デジカでは、これからこのブログを通して、Barcelonaに関する記事を多数発信していく予定です。