ミドルウェアとは? どのようなソフトウェアが開発されているか
ミドルウェアとは何か。アプリケーションではなく、OSではなく、アプリケーションに組み込まれるフレームワークでもない。単独のプログラムとして動作し、何らかの役割を担うソフトウェアといえる。例を挙げるなら、Webサーバー、データベースサーバー、キャッシュサーバーなどだ。使っている人は多いが、専門に開発している人は多くない。本セッションではまず、各スピーカーが開発したミドルウェアを紹介した。
ID採番ツール「Katsubushi」
藤原氏が開発した「Katsubushi」は、最大1023ノードの分散環境で重複しない64ビット整数のIDを採番するミドルウェアである。開発言語はGoだ。アプリケーションとの通信にはmemcachedプロトコルを使用しており、memcachedをサポートする任意の言語から利用できる。複数のデータベースで一意のIDを使用することを目的として開発された。1秒間で100万ID/ノードを取得可能である。
ID採番ツールとしては、Twitter社がScalaで開発した「Snowflake」がよく知られており、KatsubushiもSnowflakeと同様のアルゴリズムを採用している。OSSのSnowflakeを使わなかったのは、Snowflakeでは取得するIDが128ビットであり、自社用途にはサイズが大きかったこと、Scalaの知見がなかったことがその理由である。memcachedの実装は容易であり、Goで開発することに問題はなかったとのことだ。
スマホアプリ向けのプッシュ通知プロキシサーバー「Gaurun」
久保氏が開発した「Gaurun」は、スマホアプリ向けのプッシュ通知プロキシサーバーである。アプリケーションサーバーなどのクライアントからHTTP/1.1を介しJSONによってプッシュ通知リクエストを受け取り、APNs(Apple Push Notification service)やGCM(Google Cloud Messaging)/FCM(Firebase Cloud Messaging)にHTTP/2でプッシュ通知を行う。メルカリのプッシュ通知基盤として利用されている。
キャンペーン時などには数千万単位でプッシュ通知が発生するが、APNsなどに直接送ると処理に時間がかかる。クライアント側で遅延を意識せずに短時間で大容量のプッシュ通知を送るという要件を満たすために、Gaurunを開発した。開発にはGoが使われている。Gaurunは、クライアントからのリクエストをchannelベースのキューに入れ、即座にレスポンスを返す。goroutineがキューからリクエストを取り出し、APNsなどへプッシュ通知を非同期で行うことで、遅延を最低限に抑えている。
時系列データベース「Diamond」
坪内氏が開発した「Diamond」は、はてなのサーバー監視サービス「Mackerel」で使われている時系列データベースである。時系列データベースとは、時系列データに特化したデータベースであり、タイムスタンプを含む行を扱う、時系列として複数の行をグループ化して格納できるといった特徴を持つ。
以前使っていたOSSの「Graphite」は、スケーラビリティが低いという問題があった。OpenTSDB、KairosDB、InfluxDBなどの時系列データベースを検討したが、Apache CassandraやApache HBaseなど自社では未使用の技術をベースとしており、インターフェイスの関係でアプリケーションを大きく変更しなければならない。そこで、Graphiteのコンポーネントをスケールするように分解し、AWSのマネージドサービスをベースとしてDiamondを開発。インターフェイスはGraphiteとほぼ変わらない。Amazon Kinesis、AWS Lambda、Amazon ElastiCache、Amazon DynamoDB、Amazon S3などを利用し、書き込み回数が極端に増えてコストがかからないように工夫している。
分散ストレージ「Bigdam-pool」
田籠氏が開発した「Bigdam-pool」は、クラウドサービス「Treasure Data」のデータ入力パイプラインを刷新するBigdamで利用するデータバッファ用分散ストレージである。現在開発中で、言語はJavaを使用する。分散型のキーバリューストアで、数kB~数十MBの書き込みに特化しており、1秒以内であればバッファへの追記が可能だ。また、大容量のバッファの一括読み出しを想定している。プライマリキーに加え、顧客のアカウントIDやデータベースのテーブル名をセカンダリインデックスとして持つ。クラスタ内でレプリケーションを行うが、書き込み後すぐに読み出され、不要になるデータを想定しており、クラスタ内のデータ生存期間は通常は数分以内であり、レプリカの欠損が生じても自動回復は行わない。また、クラスタ間データ転送機能を備えている。
DynamoDBやCassandraなど他のキーバリューストアも検討したが、位置情報のサイズが大きく、パフォーマンスに影響が出る可能性があるため、独自開発に至ったという。