Gehirn Web Services Public Preview を開始してから半年が経ちました

きょう10月1日は、私たちが Gehirn Web Services Public Preview を開始してからちょうど半年です。

この半年間に私たちが取り組んだこと、そしてこれからのGWSについてお伝えします。

社内での利用の様子

GISは、プロジェクト機能によって複数人のチームでリソースを安全に管理できるため、組織的な利用に適しています。

ゲヒルン社内では、（当たり前ですが）GISを積極的に利用しています。

社内利用の様子をいくつかご紹介します。

DNS のマイグレーション

Gehirn DNS にはマイグレーション機能が搭載されました。 マイグレーション機能とは、指定した時刻に DNS レコードの内容を変更してくれる機能です。

ただ単にレコードの内容を変更するだけではなく、指定時刻経過後にキャッシュとして古い値が残り続けないように、指定時刻に向けて計画的にキャッシュの有効期限を調整してくれます。 このおかげで、全世界でほぼ同時に DNS レコードの値を更新することができます。

この機能を最初に利用したドメインは、 Gehirn Web Services のサービスサイトをホスティングしている www.gehirn.jp でした。

2015年4月1日の Public Preview の開始に併せてサービスサイトをリニューアルするために、従来のサービスサイトをホスティングしているサーバーから、現在のサービスサイトをホスティングしているサーバーへと A レコードの値をマイグレーション機能を用いて変更しました。

Gehirn MTA によるメーリングリストの購読

Gehirn MTA で受信したメールは Gehirn EDJ を経由して様々な手段でプッシュ通知することができます。 ゲヒルンでコミュニケーションツールとして導入している Slack への投稿も、もちろんサポートしています。

この仕組を利用して、 Debian Security Announcements などゲヒルンで利用しているソフトウェアの脆弱性情報がながれてくるメーリングリストに投稿されたメールを指定した Slack のチャンネルへ投稿しています。 このおかげでいち早く最新の脆弱性情報をチームで共有することができ、すばやく必要な対策を講じることができています。

この運用については、以前の Gehirn News の記事、 Debian Security Announcements の不正な DKIM 署名が修正されました もご参照ください。

uuid.jp と unixtime.jp

ゲヒルンでは uuid.jp というサービスを、また yosida95 個人では unixtime.jp というサービスをそれぞれ運用しています。

これらのサービスを Gehirn RS2 Plus でホスティングすることによって、他のレンタルサーバーで利用するよりもとても手軽にアプリケーションを運用することができています。

Gehirn RS2 Plus のデーモンプロセス管理機能でアプリケーションを管理することで、サーバーのリブートやアプリケーションの不具合によって意図せずアプリケーションが終了した場合でも、手動で操作をすることなく自動でアプリケーションが再起動されます。

また、 User Agent からの HTTP リクエストを WSGI リクエストに変換して uWSGI に渡す処理も、特別な操作やソフトウェアを用意することなく、 Gehirn RS2 Plus のサイト設定でバックエンドに TCP を、プロトコルに WSGI を指定するだけで行うことができます。

Slack から SMS を送信する

Slack の Outgoing Web Hook を使用すると、特定のキーワードを含む投稿を外部のAPIに通知することができます。

通知先のAPIを、Gehirn RS2 Plus とプロセス管理機能、Node.jsを活用して構築し、EDJに通知することで、一斉にSMSやメールを配送することが出来ます。

この機能を使用して、緊急時に通報用携帯端末にSMSを送信し重要な情報を速報できるようになりました。

災害時や社内で重大なイベントが発生した時に、連絡網として一斉に通報用携帯端末に通知ができるようになっています。

社内ハッカソンイベントでの利用

8月31日にゲヒルン社内ハッカソンが実施されました。

この時にも GIS が活躍しました。

社内でチームを作り、各々のテーマで開発を進めましたが、すべてのチームがインフラストラクチャにGISを選択しました。

データの集計APIを構築したり、通知のためにGISを利用していました。

ハッカソンは1日のみの開催でしたが、GISでは日割り従量課金ですので、仮にプレビュー期間後の利用であったとしても、非常に低コストでハッカソンに挑むことができます。

半年間を振り返って

この半年間、みなさまとプレビュー期間を過ごしてきましたが、お客様からのフィードバックや、社内からのフィードバックでたくさんの課題を洗い出し、解決することができました。

特に、機密性や可用性に関わる基本的な問題を解決できたことで、このプレビューの取り組みが非常に有意義であったと感じています。

この問題解決にあたって、開発チームが苦労した点や解決した課題についていくつかご紹介します。

仮想化基盤の見直し

Gehirn RS2 Plus では当初、ユーザー空間の分離にコンテナ技術を使用していました。

しかし、一つのカーネル上でたくさんのコンテナをマルチテナントで提供するには、いくつかの課題がありました。

また、プロセス空間やユーザ空間を分離できたとしても、fork-bomb攻撃でシステムがハングアップするおそれを排除できないこと、カーネルへの攻撃やシンボリックリンクを使用した攻撃で機密性を失うおそれを排除できないこと、カーネルを共有するために柔軟なアップデートスケジュールを提供できないこと、同じくカーネルを共有していることからカーネル監査ログを個別に取得することが難しいことなど、マルチテナント環境でのコンテナの提供は難しい課題がありました。

このほかにも、ページキャッシュに載ったI/O、Buffered I/Oの帯域を制御できず、深刻な性能低下を引き起こしていました。

環境を分離するにあたって、いわば、アパートの壁が薄すぎたのです。

これらの問題を解決すべく、プレビュー期間中に私たちは完全仮想化に移行することを決断しました。

移行作業は6月30日の夕方に開始し、7月1日には全ユーザのコンテナを仮想マシン上に移行しました。

現在ではきめ細かい制御や、強制アクセス制御により更に安全で高い安定性を持つサービスとなりました。

ファイルシステムがハングアップする不具合の修正

同じく Gehirn RS2 Plus において、論理ボリュームマネージャが競合状態となり、I/Oが停止してしまうことから、プロセスがI/O待ちになりシステムが徐々にハングアップする深刻な問題が生じました。

調査を進めると、論理ボリュームへの操作を行うのに必要な時間が論理ボリューム数が増えるごとに線形に増加していることに気づきました。この待ち時間がI/Oがロックされる時間でした。

残念なことに1回のボリューム操作が30分以上掛かったり、途中で処理が止まるなど開発チームの頭を悩ませました。

デバッグログとソースを追い、どの処理で時間がかかっているかを突き止め、修正することができました。

この修正によって問題は完全に解決し、ボリューム数や操作内容によらず安定して論理ボリュームやスナップショットを管理できるようになっています。

ブロックレベル増分スナップショット機能の開発

Gehirn RS2 Plus では、いくつかのクラウドサービスでも実装されているブロックレベルの増分スナップショットをサポートしています。

社内では「BIS」（Block-level Incremental Snapshot）と呼ばれています。

当初、コンテナ環境ではスナップショットで保存したボリュームのファイルをtarballにパックしてオブジェクトストレージの Gehirn KVS に転送する方法でバックアップを行っていましたが、完全仮想に移行してからはファイルシステムによらずにボリュームをまるごとバックアップする方法に転換しました。

その際に、前回のスナップショットからの増分データのみを検出し、重複排除するスナップショット機能の開発を行いました。

この機能によって、バックアップ時間・転送帯域・ディスク使用量、そしてお客様に掛かる使用料金を削減できます。

高い頻度でバックアップを行うためには、この機能の実装が欠かせませんでした。

ハードウェア障害

Gehirn RS2 Plus が安定した頃、特定のサーバが何のログも吐かずに、そして何の前触れもなく突然リセットする問題が発生しました。

当初はカーネルやファイルシステムなどを疑って調査を行いましたが、ログに何も出ていない、カーネルのダイイング・メッセージもない状態だったので、電源ユニットやマザーボードなどハードウェアの障害を疑いました。

データセンターと連絡を取り合ってハードウェアを交換したところ、同現象は全く発生しなくなりました。

データセンターにあるサーバに対して、リモートで運用を行っている場合にソフトウェアとハードウェアの問題の切り分けがやや難しかったのですが、プレビュー期間中にこのような事象に遭遇したことで、RS2 Plus サービスにおけるハードウェアの交換フローなどを実際に確認できました。

ID Center の確認コード通知フローの改良

ID Center の登録フローや、情報変更フローにおいて、一部のお客様にSMSが届かない問題が生じていました。

MNPした番号や、PHSにはSMSが届かないことがあり、その場合に音声通話による確認番号の通知にフォールバックするためのボタンを配置し、フローの改良を行いました。

この機能を実装後、お客様からSMSが届かずに登録を進められないという報告はなくなりました。

もし、以前にSMSが届かずに登録が完了しなかったお客様は、改めてお試し下さい。

Gehirn MTA の Gehirn EDJ を経由した通知の改良

「Gehirn MTA によるメーリングリストの購読」で述べたように、 Gehirn MTA で受信したメールは Gehirn EDJ を経由して Slack などのサービスへと通知することができます。

このサービスをリリースした時点では、本文が US-ASCII でエンコードされていないメールを取り扱うことができず、 Base64 や Quoted-Printable といった形式のまま Gehirn EDJ に通知されていました。

そこで Gehirn MTA のパーサーを改善し、本文が US-ASCII でないメールは UTF-8 に変換したうえで Gehirn EDJ へ通知するようにしました。

また、 Slack への通知においてはチャットメッセージとして本文をそのまま投稿していたため、長文のメッセージがそのままチャンネルに流れてしまいヒストリーが荒れるといった問題がありました。

そこで Gehirn EDJ が Slack に投稿する際は、チャット本文ではなく Attachments として投稿するように改善しました。このことによって、最初の5行以降のメッセージは折りたたまれ、 "Show more" ボタンを押さないかぎり展開されないようになりました。

開発チームがいま取り組んでいること

開発チームでは、すでに提供しているサービスについては機能の追加をフリーズし、お客様からのフィードバックや、ゲヒルンによるアプリケーションの監視によって発見された不具合の修正を主に行っています。

また、お客様がご利用する際に参照していただくためのマニュアルの準備も進めています。 Public Preview 中、マニュアルが無いことへのお叱りや、マニュアルがあればわざわざお問い合わせいただかなくとも解決いただけたユースケースもありました。 そのことを踏まえ、正式リリースまでに分かりやすいマニュアルをご提供できるように鋭意準備を進めております。

さらに、今後 Gehirn Infrastructure Services のメンバーとして、幾つもの新サービスを提供する予定もあります。それらのサービスの開発や、設計にも平行して取り組んでいます。

なお、現在 Gehirn Infrastructure Services の開発に取り組んでいるメンバーは代表の石森と技術開発部技術局の職員の yosida95 のみであり、人手の不足を痛感しています。

そこで、ゲヒルンではバックエンドエンジニア(Gehirn Web Services)を始め、あらゆる職種で職員を募集しています。 Gehirn Infrastructure Services を始め、ゲヒルンの未来を一緒に切り拓いていく仲間を募集しています。

正式化の目処

現在、年内に正式版としてみなさまにサービスを提供できるよう、開発とサポートサイトの準備を進めています。

12月までに、改めて情報を公開するとともに、課金の開始1ヶ月以上前に通知する予定です。

さらなるフィードバックの募集

プレビュー期間は現在も継続しています。

みなさまからのさらなるフィードバックをお待ちしています。

Public Preview や、フィードバックフォームの情報は「Gehirn Web Services Public Preview について」をお読み下さい。