2015.04.21 Bracket x Aratana x Gehirn 勉強会

Gehirn Infrastructure Services - https://www.gehirn.jp/gis/
Gehirn RS2 Plus - https://www.gehirn.jp/gis/rs2.html
Gehirn DNS - https://www.gehirn.jp/gis/dns.html
Gehirn MTA - https://www.gehirn.jp/gis/mta.html
Gehirn EDJ - https://www.gehirn.jp/gis/edj.html

Sentry - https://getsentry.com/

[シリーズGWS]第1回なぜゲヒルンはGWSを作ったのか - http://news.gehirn.jp/dev/615/
[シリーズGWS]第2回プロジェクト機能の役割と意味 - http://news.gehirn.jp/dev/624/
[シリーズGWS]第3回 Gehirn DNS とプロジェクトのドメイン管理 - http://news.gehirn.jp/dev/632/

Gehirn Infrastructure Services の Public Preview 開始によせて - http://yosida95.hatenablog.com/entry/2015/04/01/173000
Go at Gehirn - https://speakerdeck.com/yosida95/2015-dot-03-dot-11-gunosy-dot-go
--------------------------------------------------
今日はよろしくおねがいします。

自己紹介します。吉田昂平といいます。 twitter や GitHub 、はてなを始めとするインターネットには yosida95 として生息しています。ゲヒルンの技術開発部技術局の所属で、 2013年の8月、高校3年生の夏休みに非常勤職員として勤務を始め、2014年3月の高校卒業を待って正職員になりました。

今日のテーマです。今日は弊社ゲヒルンが提供する Gehirn Infrastructure Services について、紹介、開発、運用の3つの観点からおはなします。

まずは、サービスの紹介です。

Gehirn Infrastructure Services は今月の1日に一般公開しました。現在は Public Preview のフェーズで、無料で提供して一般の方に評価をしていただき、品質を高めるということをしています。レンタルサーバーサービスや、 DNS ホスティングサービス、メールの送受信サービスなどからなるインフラサービスで、脆弱性診断なども行っているゲヒルンの技術力を活かして、セキュアなインフラサービスという特徴を持っています。

Gehirn Infrastructure Services では、ゲヒルンの認証基盤 Gehirn ID Center を介して、 OpenID Connect によるシングルサインオンを実現しています。 Gehirn ID Center では、 ID とパスワードに、 YubiKey と Google Authenticator などがサポートする TOTP を加えた多要素認証を導入しているため、サーバーなどの大切なリソースをより強固に守ることができます。

それでは各サービスへの紹介です。まずは、レンタルサーバーサービス Gehirn RS2 PLUS。

Gehirn RS2 PLUS の特徴を幾つかご紹介します。まずは、 httpd をサイト、ホストネーム毎に Apache か TCP 、または WSGI、 FastCGI、 HTTP をサポートする任意のサーバーから選べること。例えば mod_php が必要、 Unicorn でアクセスを受けたいなど、サイトの構成によって自在に構成できます。
次に、デーモンプロセスの死活監視ができること。例えば Node.js のプロセスが突然死しても、自動的に復旧されます。また、自動起動機能も備えているため、サーバーのメンテナンスや障害などでサーバーが再起動した場合でも、何もせずにサービスを再開することができます。
Linux Container によるユーザーごとのプロセス空間の分離と、 cgroup によるリソースの制限、固定割り当てによって他のユーザーの負荷などの影響を受けること無く、安定してサービスを提供することができます。余談ですが、開発中に幾つか Linux Containers 、 LXC にバグを見つけ、開発チームにパッチを提供したところ、無事に取り込まれました。

次に Gehirn DNS です。

Gehirn DNS では、 HTTP API によりプログラマブルに DNS を構成することができます。また、各 DNS レコードの設定をバージョニングして、いつでも過去に巻き戻すことや、他の DNS レコードの設定に追従して同じ情報をレスポンスすることなどもできます。
DNS について、「浸透」や「反映」という言葉を聞いたことがあるかもしれません。これは、 DNS の設定を変更しても実際に変更したレコードを参照できるようになるまでにタイムラグが在るという意味でつかわれる言葉なのですが、実際にはそのような現象は存在しません。 TTL というレコードキャッシュの生存時間を適切に設定することで、レコードを変更した瞬間にその値を提供することができます。ただ、その設定を適切に管理することには労力が必要で、また TTL の概念自体も理解することも難しため、その管理を Gehirn DNS で代理して自動で行うマイグレーション機能も提供しています。

次に Gehirn MTA です。

Gehirn MTA は SMTP サーバーからフルスクラッチしたメール送受信サービスです。 Gehirn MTA では、 RFC ベースで 20 を超える仕様をサポートしています。また、メールの配送結果、成功、遅延、失敗などを正確にトラッキングできるため、その結果に応じてメールマガジンの配送を取りやめるなど、細かなハンドリングができます。さらに、メール受信をトリガーに、 Gehirn EDJ という次にご紹介するサービスにイベントを伝送することができるため、 HTTP Hook や SMS 通知、スマートフォンへのプッシュ通知を受け取ったりすることができます。これを使って、空メール受信で会員登録用のリンクを返信したり、などのサービスを実現することも容易です。

そして、 Gehirn EDJ。

Gehirn EDJ は、ゲヒルンからの障害情報やメンテナンス情報、 Gehirn MTA のような各サービスで発生したイベントを自由な方法で受け取るためのサービスです。
Gehirn EDJ ではイベントの受信方法として、 HTTP Hook 、 Twilio をつかった SMS 送信、 Pushover によるスマートフォンへのプッシュ通知、 Slack や IRC への通知、また Gehirn MTA を使ったメール送信をサポートしています。
そのため、例えば障害情報やメンテナンス情報を受け取って自動的にサーバーを切り替えたり、 Gehirn MTA で受け取ったメールを上記の方法で通知したり、また Gehirn MTA で受け取ったメールを別のアドレスに転送したり、あらゆるイベントをプログラマブルに受け取り、あらゆることを自動化できるだけの機能を提供しています。

それでは、 Gehirn Infrastructure Services 全体構造を簡単にご説明します。

まずは、 Contorl Panel 、これを社内では GeoFront-3 と読んでいますが、これや cURL などの API クライアントが送信した HTTPS リクエストを HTTPS API 、これを社内では CentralDogma と呼んでいますが、これで受け取ります。そうすると、 CentralDogma は認証、認可、リソースの依存関係の解決、そして RPC のルーティングを行います。その結果を RabbitMQ というメッセージキューにエンキューします。エンキューされたメッセージを、担当するサービスのワーカーがデキューし処理結果をまた RabbitMQ に返します。この独自の RPC 、リモートプロシージャコールの仕組みによって、各サービスは RabbitMQ とやりとりさえできれば、任意の言語やアーキテクチャで実装できるようになっています。
ちなみに、 RS2 PLUS と DNS は Python、 MTA と EDJ は Go 言語で書かれています。

それでは次に、 Gehirn Infrastructure Services の開発の様子についてお話します。
まずは、開発体制からです。

石森大貴、社内ニートを自称する弊社の代表が、コントロールパネルの実装と Gehirn RS2 PLUS のアーキテクチャの設計を行いました。

糠谷崇志、弊社の専務がコントロールパネルのデザインをひとりですべて行いました。

松下聡史、技術局職員が代表の石森と共同でコントロールパネルの実装を行いました。

そして、ぼくがすべてのバックエンドアプリケーションを開発しました。
以上の4人で、 Gehirn Infrastructure Services のすべてを実装しました。

次は開発の流れについてです。コードホスティングはもちろん、課題やバグ、スケジュールの管理なども GitHub を中心として行いました。
また、 GitHub にコミットが push されるたびに、 CircleCI で単体テストや e2e テストを実行し、コードの品質を維持してきました。さらに、特定のブランチに変更があるたびに、 CircleCI のテスト実行後に自動的にステージング環境やプロダクション環境にデプロイするという取り組みも行いました。

情報共有、コミュニケーションは Slack を用いて行いました。主に、上記の3つのチャンネルを目的に応じて使いました。

最後に運用の話です。

オペレーション、例えば不正利用をするユーザーの停止や、ユーザー情報の管理など、繰り返し行う操作はすべて管理者用の API として実装します。コンソールやデータベースへの人間のアクセスを出来るだけ排除することで、オペレーションミスによる重大な障害を回避するように努めています。

サービスの監視についてです。まずは、 Nagios や Munin によって障害と、その徴候を事前に検知しています。これに加えて、 Sentry というサービスによってサービスで発生した例外のトレースバックや、その発生頻度をチケットとして管理しています。過去のトレースバックなどの情報が保存されているため、デグレーションなどもすぐに検知することができます。

まとめに入ります。

Gehirn Infrastructure Services は、セキュアで高可用なインフラサービスです。このサービスでは、プロジェクトベースでのリソース、つまりサーバーや DNS ゾーンの共有と、共同作業ができます。
Gehirn Infrastructure Services は、社長や専務をはじめとるする4人という、この規模のシステムとしては少人数でリリースまで継続して開発をしました。開発は、 GitHub を中心に行い、また、 CircleCI を GitHub と連携して、継続的にテストを実行し、自動でデプロイするという取り組みも行いました。

監視は、 Nagios/Munin によるサーバーレベルと、 Sentry を使ったアプリケーションレベルの二段階で行っています。
オペレーションは十分にテストされた管理者用の API を介して行うことで、重大な人的ミスの原因を排除することに努めています。

今日、ここではお話しなかったことも軽くご紹介すると、 SMTP に関連する仕様のことや、 Go 言語の実践活用のこと、 OpenID Connect と OAuth 2.0 を使った認証と認可のこと、 CentralDogma で実施している XML による API 仕様の定義と、 RPC リクエストの自動ルーティングのことがあります。
また、監視について、 Pingdom と Pagerduty を勝手に導入して個人的に評価している最中です。

今日ここでお話したことの詳細や、今日お話しなかったことについてもご興味があれば、これから示す資料をご参照いただけると幸いです。
http://news.gehirn.jp/dev/615/
http://news.gehirn.jp/dev/624/
http://news.gehirn.jp/dev/632/

これらは、ぼくが個人的に公開している資料です。
http://yosida95.hatenablog.com/entry/2015/04/01/173000
https://speakerdeck.com/yosida95/2015-dot-03-dot-11-gunosy-dot-go

以上です。ありがとうございました。