諸事情あって、インフラ周りのスライドは削除しています

1. .NETエンタープライズWebアプリの
OSS活用
Sansan株 式 会 社
熊家 賢治

2. 今日話すこと
• 弊社サービスSansanについて
• SansanにおけるOSSの活用事例
• Webフレームワーク
• PostgreSQL、Redisとクライアントライブラリ
• インフラ

3. 自己紹介
名前
熊家 賢治(@kumake1004)
仕事
前職はパッケージ開発SE(えすいー
2011/04 Sansan株式会社入社
Sansan事業部 開発部 フレームワーク･アーキテクチャグループ
フレームワークやミドルウェアなど基盤部分の開発を担当

4. 寄稿
Build Insider
.NETライブラリ「Npgsql」によるPostgreSQLの活用
http://www.buildinsider.net/small/npgsql/01
Insider.NET(@IT)
ASP.NET WebフォームからASP.NET MVCへの移行／共存
http://www.atmarkit.co.jp/ait/articles/1308/05/news090.html

5. まとめ
Sansanについて

6. .NETでも選択肢の数は変わらない
たとえば
RDB : Oracle / PostgreSQL / MySQL
NoSQL : Memcached / Redis / MongoDB / RavenDB
Web Framework : Nancy / ServiceStack
DI : Unity / Ninject
テスト: NUnit / NSpec / SpecFlow
ロギング : log4net / NLog / Fluentd
CI : Jenkins
さらに選択肢を増やす
Build Insider - 社内の開発環境の改善＆効率化のためにNuGetを活用しよう
それぞれが作った、ちょっとしたツールやコードを
社内用NuGetリポジトリに、公開しましょう

7. ご利用は計画的に
実績には注意
GitHubならWatchやStar、Issuesなどを確認する。
NuGetならDownloadsなども参考になる。
それらを踏まえて、リスクもきちんと評価した上での採用を。
バグは、ある
テストは十分に。
できればソースコードも読む。利用する箇所だけだったり、
軽く流し読みするだけでも安心感は違う。

8. 弊社事例が、皆様の会社での
OSS導入の一助になれば幸いです
Sansanについて

9. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

10. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

11. Sansan株式会社について
名刺管理Webサービスを開発、運営
創業7年目で名刺管理に絞ったシステムを作っています。
名刺管理システム業界トップ。ちょっとだけCM流してます。
プロダクト
法人向け名刺管理Sansan
C# + ASP.NET + PostgreSQL
個人向け名刺管理Eight
Ruby on Rails + MySQL + AWS

12. 法人向けサービスSansanの特徴
ASP.NET上で動くWebアプリ
個人向けサービスに比較するとユーザ数はずっと少ない。
ソーシャルゲームなどでは100万人以上、Eightで30万人以上
Sansanは数万人、前職では数百人。
負荷
200万リクエスト/日を2台のWeb/Appサーバで。
突然跳ね上がることは滅多になく、平日の9-20時にアクセスが
集中。休日のアクセスはほぼ無い。

13. 法人向けサービスSansanの特徴
データ
ユーザ数と比較すると、おそらくデータは多い。
1億超レコードのテーブルや、数千万、数百万レコードの
テーブルが数十。たとえば、名刺テーブルは2千万超レコード。
個人向けサービスのEightは1千万超レコード。
システムに求められる要件
可用性、一貫性、アクセスコントロールなどの要求は高い。
一方で、パフォーマンスは個人向けサービスに比べると緩い。
如何に速くするか、よりも如何に確実に処理するかが重要。
また、営業やサポート部署への影響にも配慮する必要がある。

14. Sansanの構成
言語
C# 5.0 (.NET Framework 4.5)
Web/App
Windows Server 2008 R2 / IIS 7.5
キャッシュ/セッション
Redis
DB
PostgreSQL 9.1
インフラ
後述

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

16. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

17. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

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

19. Web Forms/MVC/Web API
特別な使い方はしていないので
割 愛

20. Nancy
軽量Web Framework
処理を一つのメソッドで記述。
HTTPメソッドごとルーティングを指定して処理を記述。
RubyのWeb Framework、Sinatraにインスパイア。
require ‘sinatra’
get ‘/’ do
# do something
end
post ‘/’ do
# do something
end

21. 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 => { // 省略 };
}
}

22. Nancy
用途
ログの収集解析アプリで利用。
ASP.NET & Nancy & MongoDB
やりたかったこと
やりたい処理は単純なデータ取得 > LINQ+αで加工 > 表示。
将来も含めて、MVCを利用するほどに大げさなものではなく、
容易に保守できるような作りにしたかった。

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

24. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

25. PostgreSQLについて
PostgreSQLおさらい
•
•
•
•
OSSのRDBMS
可用性向上のためのMVCCアーキテクチャ
組み込み全文検索エンジン
豊富な周辺プロダクト
pgpool-II => コネクションプーリング、レプリケーション、
負荷分散
Slony-I => レプリケーション
PL/Proxy => 水平分散
FDW => 外部データラッパー
Posgres-XC => 書き込み特化のDBクラスタ

26. なぜPostgreSQLか
最初はOracle
創業メンバーにOracle出身者がいたり、たまたま、
創業当時のエンジニアがOracleに習熟していた。
OracleからPostgreSQLへ
規模が大きくなるに従い、コストとインフラの技術的限界が
重荷になっていったため、OSSのDBを検討。
pl/pgsqlの互換性、チューニングの勘所など、
Oracleからの移行コストが低いことがPostgreSQLの
最大の決定要因になった。

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

28. C#からのPostgreSQL活用
データプロバイダはNpgsql
SQL Serverとほぼ同じ記述で利用可能で、OSSとしてはほぼ
唯一の選択肢になる。ADO.NETデータプロバイダとして大抵の
ことはできるが、Entity Frameworkへの対応はない。
品質が特別高い訳ではないことが残念なところ。
• Timeoutが既定値
• 文字列日付の日付型への変換失敗
• 大量のスレッドからの実行時、例外
• 164個のOpen Issue (資料作成時)
ただし、Github上での活動はそれなりに活発で、次期バージョン
ではEntity Frameworkもサポートされるらしい。

29. 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);
}

30. C#からのPostgreSQL活用
他の選択肢は？
有償製品になるが、dotConnectがある。
実はNpgsqlより歴史が長く、Entity Frameworkのサポートや
LINQプロバイダ、Session State Store、Membership
プロバイダなどもサポートしており、Npgsqlと比較して高機能。
• どちらを選ぶか
費用と必要とする機能を天秤に掛けて選択。
弊社では既に分厚くラップしているので今はどちらでも大した
違いはないが、今から作るならdotConnectを選びたい

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

32. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

33. Redis
Redisおさらい
•
•
•
•
Memcachedより少し豪華なインメモリKVS
データ構造(文字列、リスト、セット、ハッシュ)
永続化、レプリケーション
Redis Cluster
• 将来的にはクラスタリングも可能(度々延期してますが…)
• http://redis.shibu.jp/admin/cluster/
• P2P型で、リバランスも自動

34. Redisの活用 – キャッシュ
どこからでも使えるキャッシュ層として
クライアントライブラリにはServiceStack.Redisを利用。
コネクションプーリングやジェネリックインタフェースなどを
組み込みで持ち、気軽に利用可能で便利。
あれ？BookSleeveは？
C#+RedisはBookSleeveでは？
BuildInsider - C#のRedisライブラリ「BookSleeve」の利用法
なんでServiceStack.Redisなの？

35. ServiceStack.Redisの特徴
複数抽象度から選べるインタフェース
• RedisNativeClient
• RedisClient
• RedisTypedClient<T>
便利な機能が実装済
コネクションプールやハッシング、Pub/SubやLUAスクリプト
の実行も当然サポート。
安定
更新が頻繁で利用者数も多く、安心して利用できる。

36. ServiceStack.Redisの特徴
• Sample
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");

37. ServiceStack.Redisの特徴
いまひとつなインタフェース
RedisClient型が持つpublicメソッドの数 => 437
全てのRedisデータ型を一クラスにまとめているためこんな事に
• client.GetItemFromList()
• client.GetValueFromHash()
Redisデータ型ごとに分けるとか出来そうだが…
メソッド名も初見では少し焦る。
• client.Replace() => keyがあれば更新
• client.Add() => keyがなければ挿入
これらはそれぞれコマンドあるからしょうがないとも言えるが
Push、Pop、Enqueue、Dequeueは絶許。

38. BookSleeveの特徴
シンプルなインタフェースと非同期
基本的にはGet/Set。戻り値が特殊でTask<T>で返ってくる。
プリミティブなインタフェースで、byte[]かstringくらいしか
返せないので、そのままアプリケーションに組み込むよりは
ラップしてあげたほうが使いやすい。
詳細は以下を参照
Build Insider - C#のRedisライブラリ「BookSleeve」の利用法

39. ServiceStack.Redis or BookSleeve
どちらを使うべきか？
パフォーマンス重視ならBookSleeve、手軽なコストで使いたい
ならServiceStack.Redis、というのも今は昔。
ラップが面倒なBookSleeveも、今はCloudStructures(※)が
あるのであまり悩むこともなくなった。
※ https://github.com/neuecc/CloudStructures
なぜServiceStack.Redisか？
一番の理由は開発コスト。導入当時はラッパーがなかった。
また、当時はC#4を利用しており、非同期の扱いが手間で、
慣れない非同期を組み込むリスクも踏まえた上での判断。
Npgsqlでの反省も踏まえ更新頻度や実績(利用者数)も参考に。

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

41. Redisの活用 - セッション
セッションストアとして利用
カスタムセッションストアプロバイダはAL-Redis(※)を利用。
プロバイダはMSDNを見れば誰でも実装できるが全然速度が
出ないので注意(倍違う)。
※ https://github.com/angieslist/AL-Redis
他の選択肢
探せばいくつか出てくるが、排他制御にバグがあって高負荷時
に安定して動いてくれないので、Redisを使うならAL-Redisが
おすすめ。

42. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

43. アジェンダ
1. Sansanについて
2. Sansanの構成
1.
2.
3.
4.
Webフレームワーク
DB(PostgreSQL)
キャッシュ/セッション(Redis)
インフラ
3. まとめ

44. .NETでも選択肢の数は変わらない
たとえば
RDB : Oracle / PostgreSQL / MySQL
NoSQL : Memcached / Redis / MongoDB / RavenDB
Web Framework : Nancy / ServiceStack
DI : Unity / Ninject
テスト: NUnit / NSpec / SpecFlow
ロギング : log4net / NLog
さらに選択肢を増やす
Build Insider - 社内の開発環境の改善＆効率化のためにNuGetを活用しよう
それぞれが作った、ちょっとしたツールやコードを
社内用NuGetリポジトリに、公開しましょう

45. ご利用は計画的に
実績には注意
GitHubならWatchやStar、Issuesなどを確認する。
NuGetならDownloadsなども参考になる。
それらを踏まえて、リスクもきちんと評価した上での採用を。
バグは、ある
テストは十分に。
できればソースコードも読む。利用する箇所だけだったり、
軽く流し読みするだけでも安心感は違う。

46. 弊社事例が、皆様の会社での
OSS導入の一助になれば幸いです
Sansanについて

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

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