Ruby PaaS「MOGOK」

リソース管理とメッセージング

PaaSの環境を考えるときに、アプリケーション実行環境は、ユーザから見て独立している必要があります。アプリケーション実行環境ごとにVMを準備する方法もありますが、集約や管理という観点でオーバーヘッドが大きくなります。そこで、効率的集約とアプリケーションの独立性を高める方法を考える必要がでてきます。MOGOKはαバージョンで、環境独立の担保として「chroot」を用いました。これは古くからUNIXで利用される技術であるのですが、CPUやメモリ等の計算機資源をユーザ単位では管理しにくく、ユーザに見せる必要がない情報まで見えてしまうものでした。そこでβバージョンからは、Linuxのcgroupとnamespaceという機能を用いて、chrootではカバーできなかった制限を行いました。これにより、CPUとメモリ制限の自由度の拡張と、ユーザに見せる必要のない情報の隠ぺいが実現され、ユーザリソースの制御が容易な独立環境へと改良されました。

次に、MOGOK内部のメッセージ通信に関しての手法を説明します。MOGOKの内部ではPaaSを実現するために、色々な機能を持ったサーバが動作しています。先にあげたユーザアプリケーションを動作させる環境や、ユーザからのHTTPリクエストをルーティングするサーバ、データベースを作成・管理するサーバ群等です。PaaSを考える上で、それらサーバ群は将来的なサービスのスケールアウトに対応できるように、台数が増加しても管理しやすい機構になっていなければなりません。今回MOGOKを設計するにあたり、すべてのシステムをAPIで統合するという形でグランドデザインを描きましたが、各サーバが独自に特定サーバとのやり取りを行うと、将来的にサーバ数が増えた場合、メッシュに近い形でAPI呼び出しが行われてしまい、システムとして複雑でメンテナンスを行いにくくなってしまいます。そこで、このやり取りを簡素化するために、メッセージングルータを導入しました。これをMOGOKではPX（Procedure Exchange）と呼び、すべてのAPIリクエストはこのPXを経由してやり取りするようにしました。PXは特定のルーティング情報を保持し、入力されたAPIリクエストを解析して宛先サーバへと転送します。メッセージを送りたいプログラムは、IPアドレスやドメイン名等を気にせずに、APIリクエストを投げるデフォルトルータとしてPXを指定することになります。この機構により、将来的にサーバが増えたとしてもPXにリクエストさえ投げこめば、適切なサーバへとAPIリクエストがルーティングされることになります。PXは中央集権的な機構に見え、単一障害点に見えるかもしれません。しかし、PX自身が受け付けたリクエストに対する状態を保持しないので、複数サーバでVirtual IPを利用した冗長構成を組めるようにすることで、単一障害点にはなりにくい仕組みになりました。なお、PXで利用されるメッセージングの仕組みには、オープンソースソフトウェアのMessagePack-RPCを利用しています。