Go Conference 2014 Autumnレポート

Go Conference 2014 Autumn,その他のセッションのまとめ

この記事を読むのに必要な時間:およそ 5 分

Golang JP Community (@qt_luigi氏

このセッションでは,@qt_luigi氏から日本のGo言語のコミュニティについての紹介がされていました。なお,このセッションの発表資料は,以下のURLから閲覧することができます。

写真2 @qt_luigi氏の発表の様子

写真2 @qt_luigi氏の発表の様子

Golang JP Community(Google+)

まずはじめに,同氏が管理しているGoogle+のGolang JP Communityについての紹介が行われました。Google+上のGo言語のコミュニティでは5番目の規模(発表当時)であるそうです。本稿執筆時には641人の方が参加されていました。同氏は多くの方にこのコミュニティに参加して,投稿(または+1)してほしいと述べていました。

日本各地の勉強会

つぎに2014年に日本各地で行われたGo言語の勉強会について紹介されていました。2014年にはおよそ140の勉強会が日本各地で行われたそうです。その中でも,定期的に行われている勉強会について紹介が行われました。

関東
  • Go Conference:毎年春と秋に行われる日本最大のGo言語のカンファレンス
  • タネマキGAE:Google App Engine for GoとPythonについての勉強会
  • Tokyo Golang Developers:日本に住む外国人が中心になって行っているイベント
  • 質実Go研:主にGo言語の標準パッケージのコードリーディングや参加者でさまざまな課題の実装方法模索するイベント
  • Go弱の会:初心者向けのイベント
  • 大井町Go:大井町で行われている勉強会
  • Gunosy.go:株式会社Gunosyで行われる勉強会
  • ヒカルのGo:株式会社ディー・エヌ・エー(ヒカリエ)で行われる勉強会
  • dwanGo:株式会社ドワンゴで行われる勉強会
その他の地域
  • Shizuoka.go:静岡で行われる勉強会
  • Golang Cafe:GDGChugoku主催の勉強会でGo言語の勉強会では開催数は最多
  • Fukuoka.go:福岡で行われる勉強会

インターネット上の情報源

さいごにGo言語に関するインターネット上の情報源について紹介がされていました。

NSQ-Centric Architecture(Greg氏)

このセッションでは,Greg氏からNSQを使って開発したチャットシステムの構造について説明されました。なお,このセッションの発表資料は,以下のURLから閲覧することができます。

写真3 Greg氏の発表の様子

写真3 Greg氏の発表の様子

NSQ

NSQとは,bit.lyが開発しているGo言語で書かれたメッセージキューであるそうです。同氏は,以下の要件を実現するために,NSQを採用したと説明していました。

  • チャットサーバを作る
  • リアルタイム
  • スケールしやすい
  • 分散
  • 柔軟でシンプルに設定できる
  • Go言語で書きたい
  • アプリ内Webviewで使うためWebsocketを利用
  • ロードバランスさせたい

同氏はNSQの特徴として以下の点を挙げていました。

  • 単一障害点(SPOF)がない分散システム
  • 横にスケールしやすい
  • レイテンシーが低く,プッシュでメッセージを送る
  • ロードバラスもマルチキャストもできる
  • データフォーマットは何でも利用できる

また,NSQの決まり事(Guarantees)として以下の点を挙げていました。

  • デフォルトでは永続化されない
  • メッセージは必ず1回以上届く
  • メッセージが届く順序は決まっていない
  • コンシューマは少し時間がかかっても最終的には全部のトピックを見つける

なお,永続化を保証したい場合は,--mem-queue-size=0というオプションを付けると良いと同氏は述べていました。

NSQにはトピック,チャネル(Go言語のチャネルとは別⁠⁠,コンシューマという3つの概念があるそうです。メッセージはトピックに送られ,そしてトピックに関連付けられているチャネルにコピーされます。チャネルは最終的にメッセージを受け取るコンシューマを持ち,チャネルに複数のコンシューマが存在する場合は,メッセージはランダムに各コンシューマに届けられるそうです。また,チャネルにコンシューマが存在しない場合は,メッセージは破棄されず保管されるそうです。

WebviewでiMessage風なアプリを作る

プロトコル

同氏はNSQを使って,WebviewでiMessage風なアプリを実現したいと考えていたそうです。そして,このシステムで使用するプロトコルは以下のようなものを想定したそうです。

  • シンプルなJSON
  • サーバ同士とサーバ・クライアントのやりとりが同じ形式
  • ルーティングしやすい

最終的に,メッセージは以下のような形式になったそうです。

{
  "type":<message-type>,
  "to":<recipient-id>,
  "body:" {
    ...
  }
}
チャネル

同氏はいくつかの用途によって以下のチャネルを作成したそうです。

  • Websocketチャネル
  • アーカイブチャネル
  • プッシュチャネル
  • マイクロサービス

Websocketチャネルは以下のように実装したそうです。

  • Websocketサーバ1台につき1チャネル
  • すべてのメッセージがすべてのサーバに届くため,宛先を見て関係無いものは無視をする
  • ネットワーク障害があった場合はNSQがメッセージを保管する
  • 分散(少なくともマルチプレックス)チャットになる

また,アーカイブチャネルは以下のように実装したそうです。

  • 1つのチャネルに複数のコンシューマ
  • すべてのメッセージを受取り,DBに書き込む
  • ロードバランスを実現するためには,単にサーバを足せばよい
  • アーカイブプロセスとDBを同じサーバにすれば直接メッセージをDBに送ることができる

プッシュチャネルは以下のように実装したそうです。

  • 1つのチャネルに1つのコンシューマ
  • チャットメッセージと既読メッセージを受け取って,未読数を数える
  • 「新着メッセージが◯件あります。」というプッシュ通知を送る

現在はプッシュサーバが1台であるそうですが,じきに複数台にして分散させる予定だと同氏は述べていました。

NSQを利用して開発したシステムでは,チャネルを追加することでマイクロサービスを追加できるそうです。また,同氏はNSQの管理画面からトピックとチャネルの一時停止もでき,デプロイも容易であると述べていました。

クライアントサイド

同氏は,クライアントサイドを実装するうえで,以下のことを考慮しなければならなかったと述べていました。

  • メッセージが届く順番が決まっていない
  • メッセージは2回以上届く可能性がある

同氏はメッセージは,日付でソートすれば良いと述べていました。ただし,サーバ間で時計を合わせておく必要があると指摘していました。また,メッセージはUUIDを使って管理しておけば,重複しているかどうか分かると主張していました。なお,メッセージが更新されたかどうかは,バージョンや日付で見分けると良いと述べていました。

著者プロフィール

上田拓也(うえだたくや)

KLab(株)所属。Go Conference 2014 Autumnスタッフ。

業務ではJavaScript,Luaなどを扱っている。

大学時代にGo言語に出会い,それ以来Go言語にのめり込む。

時間があると,Go言語の勉強会に参加している。

Go言語のマスコットのGopherの絵を描くのも好き。

Twitter:@tenntenn