Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

ミドルウェアならではの開発者の悩み――スケーラビリティやソフトウェア寿命の問題にどう立ち向かうか

「エンジニアサポートCROSS 2017」セッション「人はなぜミドルウェアを作ってしまうのか?」レポート

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2017/10/27 14:00

 2017年9月8日、国内最大級のIT系勉強会「エンジニアサポートCROSS 2017」が開催された。通算6回目を迎える同イベントでは、「LOW TECH×HIGH TECH」とテーマとして昨今変化・複雑化する技術の話題を交差させるセッションが行われた。本稿では、トレジャーデータ株式会社 田籠聡氏、株式会社カヤック 藤原俊一郎氏、株式会社メルカリ 久保達彦氏、株式会社はてな 坪内佑樹氏の4名が集まり、ミドルウェアについて語り合ったセッションの様子をレポートする。

目次

ミドルウェアとは? どのようなソフトウェアが開発されているか

 ミドルウェアとは何か。アプリケーションではなく、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で開発することに問題はなかったとのことだ。

Katsubushi
Katsubushi

スマホアプリ向けのプッシュ通知プロキシサーバー「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などへプッシュ通知を非同期で行うことで、遅延を最低限に抑えている。

Gaurun
Gaurun

時系列データベース「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などを利用し、書き込み回数が極端に増えてコストがかからないように工夫している。

Diamond
Diamond

分散ストレージ「Bigdam-pool」

トレジャーデータ株式会社 ソフトウェアエンジニア 田籠聡氏
トレジャーデータ株式会社 ソフトウェアエンジニア 田籠聡氏

 田籠氏が開発した「Bigdam-pool」は、クラウドサービス「Treasure Data」のデータ入力パイプラインを刷新するBigdamで利用するデータバッファ用分散ストレージである。現在開発中で、言語はJavaを使用する。分散型のキーバリューストアで、数kB~数十MBの書き込みに特化しており、1秒以内であればバッファへの追記が可能だ。また、大容量のバッファの一括読み出しを想定している。プライマリキーに加え、顧客のアカウントIDやデータベースのテーブル名をセカンダリインデックスとして持つ。クラスタ内でレプリケーションを行うが、書き込み後すぐに読み出され、不要になるデータを想定しており、クラスタ内のデータ生存期間は通常は数分以内であり、レプリカの欠損が生じても自動回復は行わない。また、クラスタ間データ転送機能を備えている。

 DynamoDBやCassandraなど他のキーバリューストアも検討したが、位置情報のサイズが大きく、パフォーマンスに影響が出る可能性があるため、独自開発に至ったという。

Bigdam-pool
Bigdam-pool

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 坂井 直美(サカイ ナオミ)

    SE、通信教育講座の編集、IT系出版社の書籍編集を経てフリーランスへ。IT分野で原稿を書いたり編集したり翻訳したり。

バックナンバー

連載:イベントレポート

もっと読む

All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5