ソフトウェア方面の先進テクノロジー～ Sansan 流の業務系アプリ開発者視点 ～

Sansan 株式会社藤倉 成太

• 弊社サービス Sansan について• Sansan における OSS の活用事例

• Web フレームワーク• PostgreSQL 、 Redis とクライアントライブラリ• インフラ

今日話すこと

名前 藤倉 成太（フジクラ シゲモト）

仕事 Sansan 事業部 開発部部長 アーキテクト 2009 年 Sansan 入社

自己紹介

Sansan についてまとめ

たとえばRDB : Oracle / PostgreSQL / MySQLNoSQL : Memcached / Redis / MongoDB / RavenDBWeb Framework : Nancy / ServiceStackDI : Unity / Ninjectテスト : NUnit / NSpec / SpecFlowロギング : log4net / NLog / FluentdCI : Jenkins

さらに選択肢を増やすBuild Insider - 社内の開発環境の改善＆効率化のためにNuGet

を活用しようそれぞれが作った、ちょっとしたツールやコードを社内用 NuGet リポジトリに、公開しましょう

.NET でも選択肢の数は変わらない

実績には注意GitHub なら Watch や Star 、 Issues などを確認する。NuGet なら Downloads なども参考になる。それらを踏まえて、リスクもきちんと評価した上での採用を。

バグは、あるテストは十分に。できればソースコードも読む。利用する箇所だけだったり、軽く流し読みするだけでも安心感は違う。

ご利用は計画的に

Sansan について弊社事例が、皆様の会社での

OSS 導入の一助になれば幸いです

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

名刺管理 Web サービスを開発、運営創業 7 年目で名刺管理に絞ったシステムを作っています。名刺管理システム業界トップ。ちょっとだけ CM 流してます。

プロダクト法人向け名刺管理 SansanC# + ASP.NET + PostgreSQL

個人向け名刺管理 EightRuby on Rails + MySQL + AWS

Sansan 株式会社について

ASP.NET 上で動く Web アプリ個人向けサービスに比較するとユーザ数はずっと少ない。ソーシャルゲームなどでは 100 万人以上、 Eight で 50 万人以上Sansan は数万人、前職では数百人。

負荷200 万リクエスト / 日を 2 台の Web/App サーバで。突然跳ね上がることは滅多になく、平日の 9-20 時にアクセスが集中。休日のアクセスはほぼ無い。

法人向けサービス Sansan の特徴

データユーザ数と比較すると、おそらくデータは多い。1 億超レコードのテーブルや、数千万、数百万レコードのテーブルが数十。たとえば、名刺テーブルは 2 千万超レコード。個人向けサービスの Eight は 1 千万超レコード。

システムに求められる要件可用性、一貫性、アクセスコントロールなどの要求は高い。一方で、パフォーマンスは個人向けサービスに比べると緩い。如何に速くするか、よりも如何に確実に処理するかが重要。また、営業やサポート部署への影響にも配慮する必要がある。

法人向けサービス Sansan の特徴

言語C# 5.0 (.NET Framework 4.5)

Web/AppWindows Server 2008 R2 / IIS 7.5

キャッシュ / セッションRedis

DBPostgreSQL 9.1

インフラ後述

Sansan の構成

生産性創業当初の限られた人員で Web/ クライアント (※)/ 社内システム全てを作る必要があった。クライアント OS は最も一般的な Windows をターゲットに、Windows+ 高生産性＝Windows Forms を採用するに至る。スキルを応用できるし、という理由で Web も。

※スキャナと連携する名刺登録アプリケーション

なぜ C# か

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

フレームワークプロダクトは Web Forms/MVC/Web API併用。社内ツールに Nancy

Web/App

特別な使い方はしていないので

割　愛

Web Forms/MVC/Web API

軽量Web Framework処理を一つのメソッドで記述。HTTPメソッドごとルーティングを指定して処理を記述。Ruby の Web Framework 、 Sinatra にインスパイア。

Nancy

require ‘sinatra’get ‘/’ do # do somethingend

post ‘/’ do # do somethingend

Nancy

public class MyModule : NancyModule { public MyModule() { Get[“/page/{id}”] = param => { // データ取得 var data = new DbClient().GetData(param.id); // データ加工 var responceData = data.Select(_ => _.Value);　　　　　 // データ表示 return View["page", new { Data = responceData }]; }; Post[“/regist”] = param => { // 省略 }; }}

用途ログの収集解析アプリで利用。ASP.NET & Nancy & MongoDB

やりたかったことやりたい処理は単純なデータ取得 > LINQ+α で加工 > 表示。将来も含めて、 MVC を利用するほどに大げさなものではなく、容易に保守できるような作りにしたかった。

Nancy

結果一つのメソッドに処理が集まるので、自然とシンプルに実装するようになり、ルーティングも一目で分かるのでデバッグや保守が非常に容易に。とにかく気軽に API を作成できるので、ちょっと Linux サーバと

の連携を取りたい時にも利用している。

Nancy

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

PostgreSQL おさらい• OSS の RDBMS• 可用性向上のための MVCC アーキテクチャ• 組み込み全文検索エンジン• 豊富な周辺プロダクト

pgpool-II => コネクションプーリング、レプリケーション、負荷分散

Slony-I => レプリケーションPL/Proxy => 水平分散FDW => 外部データラッパーPosgres-XC => 書き込み特化の DB クラスタ

PostgreSQL について

最初は Oracle創業メンバーに Oracle出身者がいたり、たまたま、創業当時のエンジニアが Oracle に習熟していた。

Oracle から PostgreSQL へ規模が大きくなるに従い、コストとインフラの技術的限界が重荷になっていったため、 OSS の DB を検討。

pl/pgsql の互換性、チューニングの勘所など、Oracle からの移行コストが低いことが PostgreSQL の最大の決定要因になった。

なぜ PostgreSQL か

クエリ、設計の最適化極端な高パフォーマンスは必要とされていないので、基本に忠実に作ることを心がける。seq scan させない、頻繁に使うデータは必ずメモリに格納し、ディスク I/O を削減する。主要テーブルの Cache Hit Rate はCacti で常に監視して 99％以上を保つ。

これらの実現のために、コードレビューとは別にSQL/ テーブル設計レビューを実施している。

パフォーマンス維持の工夫

データプロバイダは NpgsqlSQL Server とほぼ同じ記述で利用可能で、 OSS としてはほぼ唯一の選択肢になる。 ADO.NET データプロバイダとして大抵のことはできるが、 Entity Framework への対応はない。品質が特別高い訳ではないことが残念なところ。

• Timeout が既定値• 文字列日付の日付型への変換失敗• 大量のスレッドからの実行時、例外• 164 個の Open Issue (資料作成時 )

ただし、 Github 上での活動はそれなりに活発で、次期バージョンでは Entity Framework もサポートされるらしい。

C# からの PostgreSQL 活用

Npgsql サンプルコード

using (var conn = new NpgsqlConnection(connStr)){ conn.Open(); var dataAdapter = new NpgsqlDataAdapter( @"select * from table_name", conn); var dataSet = new DataSet(); dataAdapter.Fill(dataSet);}

他の選択肢は？有償製品になるが、 dotConnect がある。実は Npgsql より歴史が長く、 Entity Framework のサポートやLINQ プロバイダ、 Session State Store 、 Membershipプロバイダなどもサポートしており、 Npgsql と比較して高機能。

• どちらを選ぶか費用と必要とする機能を天秤に掛けて選択。弊社では既に分厚くラップしているので今はどちらでも大した違いはないが、今から作るなら dotConnect を選びたい

C# からの PostgreSQL 活用

困ることはまずない今は Entity Framework が使えないので初期コストが高くなるケースもある。が、運用していく為の周辺環境 ( ツールや情報 )は充実しているので埋め合わせは十分に可能。C# だから SQL Server 、ではなく、純粋に要件やエンジニアの保有スキルにあわせて DB を選択すべき。

C# からの PostgreSQL 活用

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

Redis おさらい• Memcached より少し豪華なインメモリ KVS• データ構造 (文字列、リスト、セット、ハッシュ )• 永続化、レプリケーション• Redis Cluster

• 将来的にはクラスタリングも可能 (度々延期してますが… )

• http://redis.shibu.jp/admin/cluster/• P2P型で、リバランスも自動

Redis

どこからでも使えるキャッシュ層としてクライアントライブラリには ServiceStack.Redis を利用。コネクションプーリングやジェネリックインタフェースなどを組み込みで持ち、気軽に利用可能で便利。

あれ？ BookSleeve は？C#+Redis は BookSleeve では？

BuildInsider - C#のRedisライブラリ「BookSleeve」の利用法

なんで ServiceStack.Redis なの？

Redis の活用 – キャッシュ

複数抽象度から選べるインタフェース• RedisNativeClient• RedisClient• RedisTypedClient<T>

便利な機能が実装済コネクションプールやハッシング、 Pub/Sub や LUA スクリプトの実行も当然サポート。

安定更新が頻繁で利用者数も多く、安心して利用できる。

ServiceStack.Redis の特徴

• Sample

ServiceStack.Redis の特徴

var client = new RedisNativeClient("127.0.0.1", 6379);var value = client.LPop("list-key");

var client = new RedisClient("127.0.0.1", 6379);var value = client.As<Model>().GetItemFromList("list-key");

var manager = new PooledRedisClientManager("127.0.0.1:6379");var client = manager.GetClient();var value = client.Get<Model>("key");

いまひとつなインタフェースRedisClient型が持つ publicメソッドの数 => 437全ての Redis データ型を一クラスにまとめているためこんな事

に• client.GetItemFromList()• client.GetValueFromHash()

Redis データ型ごとに分けるとか出来そうだが…

メソッド名も初見では少し焦る。• client.Replace() => key があれば更新• client.Add() => key がなければ挿入

これらはそれぞれコマンドあるからしょうがないとも言えるがPush 、 Pop 、 Enqueue 、 Dequeue は絶許。

ServiceStack.Redis の特徴

シンプルなインタフェースと非同期基本的には Get/Set 。戻り値が特殊で Task<T> で返ってくる。プリミティブなインタフェースで、 byte[] か string くらいしか返せないので、そのままアプリケーションに組み込むよりはラップしてあげたほうが使いやすい。

詳細は以下を参照Build Insider - C#のRedisライブラリ「BookSleeve」の利用法

BookSleeve の特徴

どちらを使うべきか？パフォーマンス重視なら BookSleeve 、手軽なコストで使いたいなら ServiceStack.Redis 、というのも今は昔。ラップが面倒な BookSleeve も、今は CloudStructures(※) があるのであまり悩むこともなくなった。※ https://github.com/neuecc/CloudStructures

なぜ ServiceStack.Redis か？一番の理由は開発コスト。導入当時はラッパーがなかった。また、当時は C#4 を利用しており、非同期の扱いが手間で、慣れない非同期を組み込むリスクも踏まえた上での判断。Npgsql での反省も踏まえ更新頻度や実績 ( 利用者数 ) も参考に。

ServiceStack.Redis or BookSleeve

シリアライズ / デシリアライズGoogle謹製 protocol buffers の .NET 実装、 protobuf-net 。軽量かつ高速、 Google での利用実績もあって即決。同類に MessagePack for CLI があったが、当時はprotobuf-net と比較するとパフォーマンス、実績の点で欠けた( ただし利便性は MessagePack の方が良かった )

Redis の活用 - キャッシュ

セッションストアとして利用カスタムセッションストアプロバイダは AL-Redis(※) を利用。プロバイダは MSDN を見れば誰でも実装できるが全然速度が出ないので注意 (倍違う ) 。※ https://github.com/angieslist/AL-Redis

他の選択肢探せばいくつか出てくるが、排他制御にバグがあって高負荷時に安定して動いてくれないので、 Redis を使うなら AL-Redis がおすすめ。

Redis の活用 - セッション

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

1. Sansan について2. Sansan の構成

1. Web フレームワーク2. DB(PostgreSQL)3. キャッシュ / セッション (Redis)4. インフラ

3. まとめ

アジェンダ

たとえばRDB : Oracle / PostgreSQL / MySQLNoSQL : Memcached / Redis / MongoDB / RavenDBWeb Framework : Nancy / ServiceStackDI : Unity / Ninjectテスト : NUnit / NSpec / SpecFlowロギング : log4net / NLog

さらに選択肢を増やすBuild Insider - 社内の開発環境の改善＆効率化のためにNuGet

を活用しようそれぞれが作った、ちょっとしたツールやコードを社内用 NuGet リポジトリに、公開しましょう

.NET でも選択肢の数は変わらない

実績には注意GitHub なら Watch や Star 、 Issues などを確認する。NuGet なら Downloads なども参考になる。それらを踏まえて、リスクもきちんと評価した上での採用を。

バグは、あるテストは十分に。できればソースコードも読む。利用する箇所だけだったり、軽く流し読みするだけでも安心感は違う。

ご利用は計画的に

Sansan について弊社事例が、皆様の会社での

OSS 導入の一助になれば幸いです

• 仲間を募集しています• http://www.sansan.com/recruit/engineer/

最後に

ご清聴ありがとうございました。