20131209_buildinsidermeetup

3,347 views

Published on

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

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,347
On SlideShare
0
From Embeds
0
Number of Embeds
1,149
Actions
Shares
0
Downloads
20
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

20131209_buildinsidermeetup

  1. 1. .NETエンタープライズWebアプリの OSS活用 Sansan株 式 会 社 熊家 賢治
  2. 2. 今日話すこと • 弊社サービスSansanについて • SansanにおけるOSSの活用事例 • Webフレームワーク • PostgreSQL、Redisとクライアントライブラリ • インフラ
  3. 3. 自己紹介 名前 熊家 賢治(@kumake1004) 仕事 前職はパッケージ開発SE(えすいー 2011/04 Sansan株式会社入社 Sansan事業部 開発部 フレームワーク・アーキテクチャグループ フレームワークやミドルウェアなど基盤部分の開発を担当
  4. 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. 5. まとめ Sansanについて
  6. 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. 7. ご利用は計画的に 実績には注意 GitHubならWatchやStar、Issuesなどを確認する。 NuGetならDownloadsなども参考になる。 それらを踏まえて、リスクもきちんと評価した上での採用を。 バグは、ある テストは十分に。 できればソースコードも読む。利用する箇所だけだったり、 軽く流し読みするだけでも安心感は違う。
  8. 8. 弊社事例が、皆様の会社での OSS導入の一助になれば幸いです Sansanについて
  9. 9. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  10. 10. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  11. 11. Sansan株式会社について 名刺管理Webサービスを開発、運営 創業7年目で名刺管理に絞ったシステムを作っています。 名刺管理システム業界トップ。ちょっとだけCM流してます。 プロダクト 法人向け名刺管理Sansan C# + ASP.NET + PostgreSQL 個人向け名刺管理Eight Ruby on Rails + MySQL + AWS
  12. 12. 法人向けサービスSansanの特徴 ASP.NET上で動くWebアプリ 個人向けサービスに比較するとユーザ数はずっと少ない。 ソーシャルゲームなどでは100万人以上、Eightで30万人以上 Sansanは数万人、前職では数百人。 負荷 200万リクエスト/日を2台のWeb/Appサーバで。 突然跳ね上がることは滅多になく、平日の9-20時にアクセスが 集中。休日のアクセスはほぼ無い。
  13. 13. 法人向けサービスSansanの特徴 データ ユーザ数と比較すると、おそらくデータは多い。 1億超レコードのテーブルや、数千万、数百万レコードの テーブルが数十。たとえば、名刺テーブルは2千万超レコード。 個人向けサービスのEightは1千万超レコード。 システムに求められる要件 可用性、一貫性、アクセスコントロールなどの要求は高い。 一方で、パフォーマンスは個人向けサービスに比べると緩い。 如何に速くするか、よりも如何に確実に処理するかが重要。 また、営業やサポート部署への影響にも配慮する必要がある。
  14. 14. Sansanの構成 言語 C# 5.0 (.NET Framework 4.5) Web/App Windows Server 2008 R2 / IIS 7.5 キャッシュ/セッション Redis DB PostgreSQL 9.1 インフラ 後述
  15. 15. なぜC#か 生産性 創業当初の限られた人員でWeb/クライアント(※)/社内システム 全てを作る必要があった。 クライアントOSは最も一般的なWindowsをターゲットに、 Windows+高生産性=Windows Formsを採用するに至る。 スキルを応用できるし、という理由でWebも。 ※スキャナと連携する名刺登録アプリケーション
  16. 16. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  17. 17. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  18. 18. Web/App フレームワーク プロダクトはWeb Forms/MVC/Web API併用。 社内ツールにNancy
  19. 19. Web Forms/MVC/Web API 特別な使い方はしていないので 割 愛
  20. 20. Nancy 軽量Web Framework 処理を一つのメソッドで記述。 HTTPメソッドごとルーティングを指定して処理を記述。 RubyのWeb Framework、Sinatraにインスパイア。 require ‘sinatra’ get ‘/’ do # do something end post ‘/’ do # do something end
  21. 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. 22. Nancy 用途 ログの収集解析アプリで利用。 ASP.NET & Nancy & MongoDB やりたかったこと やりたい処理は単純なデータ取得 > LINQ+αで加工 > 表示。 将来も含めて、MVCを利用するほどに大げさなものではなく、 容易に保守できるような作りにしたかった。
  23. 23. Nancy 結果 一つのメソッドに処理が集まるので、自然とシンプルに実装する ようになり、ルーティングも一目で分かるのでデバッグや保守が 非常に容易に。 とにかく気軽にAPIを作成できるので、ちょっとLinuxサーバとの 連携を取りたい時にも利用している。
  24. 24. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  25. 25. PostgreSQLについて PostgreSQLおさらい • • • • OSSのRDBMS 可用性向上のためのMVCCアーキテクチャ 組み込み全文検索エンジン 豊富な周辺プロダクト pgpool-II => コネクションプーリング、レプリケーション、 負荷分散 Slony-I => レプリケーション PL/Proxy => 水平分散 FDW => 外部データラッパー Posgres-XC => 書き込み特化のDBクラスタ
  26. 26. なぜPostgreSQLか 最初はOracle 創業メンバーにOracle出身者がいたり、たまたま、 創業当時のエンジニアがOracleに習熟していた。 OracleからPostgreSQLへ 規模が大きくなるに従い、コストとインフラの技術的限界が 重荷になっていったため、OSSのDBを検討。 pl/pgsqlの互換性、チューニングの勘所など、 Oracleからの移行コストが低いことがPostgreSQLの 最大の決定要因になった。
  27. 27. パフォーマンス維持の工夫 クエリ、設計の最適化 極端な高パフォーマンスは必要とされていないので、 基本に忠実に作ることを心がける。 seq scanさせない、頻繁に使うデータは必ずメモリに格納し、 ディスクI/Oを削減する。主要テーブルのCache Hit Rateは Cactiで常に監視して99%以上を保つ。 これらの実現のために、コードレビューとは別に SQL/テーブル設計レビューを実施している。
  28. 28. C#からのPostgreSQL活用 データプロバイダはNpgsql SQL Serverとほぼ同じ記述で利用可能で、OSSとしてはほぼ 唯一の選択肢になる。ADO.NETデータプロバイダとして大抵の ことはできるが、Entity Frameworkへの対応はない。 品質が特別高い訳ではないことが残念なところ。 • Timeoutが既定値 • 文字列日付の日付型への変換失敗 • 大量のスレッドからの実行時、例外 • 164個のOpen Issue (資料作成時) ただし、Github上での活動はそれなりに活発で、次期バージョン ではEntity Frameworkもサポートされるらしい。
  29. 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. 30. C#からのPostgreSQL活用 他の選択肢は? 有償製品になるが、dotConnectがある。 実はNpgsqlより歴史が長く、Entity Frameworkのサポートや LINQプロバイダ、Session State Store、Membership プロバイダなどもサポートしており、Npgsqlと比較して高機能。 • どちらを選ぶか 費用と必要とする機能を天秤に掛けて選択。 弊社では既に分厚くラップしているので今はどちらでも大した 違いはないが、今から作るならdotConnectを選びたい
  31. 31. C#からのPostgreSQL活用 困ることはまずない 今はEntity Frameworkが使えないので初期コストが高くなる ケースもある。が、運用していく為の周辺環境(ツールや情報) は充実しているので埋め合わせは十分に可能。 C#だからSQL Server、ではなく、純粋に要件やエンジニアの 保有スキルにあわせてDBを選択すべき。
  32. 32. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  33. 33. Redis Redisおさらい • • • • Memcachedより少し豪華なインメモリKVS データ構造(文字列、リスト、セット、ハッシュ) 永続化、レプリケーション Redis Cluster • 将来的にはクラスタリングも可能(度々延期してますが…) • http://redis.shibu.jp/admin/cluster/ • P2P型で、リバランスも自動
  34. 34. Redisの活用 – キャッシュ どこからでも使えるキャッシュ層として クライアントライブラリにはServiceStack.Redisを利用。 コネクションプーリングやジェネリックインタフェースなどを 組み込みで持ち、気軽に利用可能で便利。 あれ?BookSleeveは? C#+RedisはBookSleeveでは? BuildInsider - C#のRedisライブラリ「BookSleeve」の利用法 なんでServiceStack.Redisなの?
  35. 35. ServiceStack.Redisの特徴 複数抽象度から選べるインタフェース • RedisNativeClient • RedisClient • RedisTypedClient<T> 便利な機能が実装済 コネクションプールやハッシング、Pub/SubやLUAスクリプト の実行も当然サポート。 安定 更新が頻繁で利用者数も多く、安心して利用できる。
  36. 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. 37. ServiceStack.Redisの特徴 いまひとつなインタフェース RedisClient型が持つpublicメソッドの数 => 437 全てのRedisデータ型を一クラスにまとめているためこんな事に • client.GetItemFromList() • client.GetValueFromHash() Redisデータ型ごとに分けるとか出来そうだが… メソッド名も初見では少し焦る。 • client.Replace() => keyがあれば更新 • client.Add() => keyがなければ挿入 これらはそれぞれコマンドあるからしょうがないとも言えるが Push、Pop、Enqueue、Dequeueは絶許。
  38. 38. BookSleeveの特徴 シンプルなインタフェースと非同期 基本的にはGet/Set。戻り値が特殊でTask<T>で返ってくる。 プリミティブなインタフェースで、byte[]かstringくらいしか 返せないので、そのままアプリケーションに組み込むよりは ラップしてあげたほうが使いやすい。 詳細は以下を参照 Build Insider - C#のRedisライブラリ「BookSleeve」の利用法
  39. 39. ServiceStack.Redis or BookSleeve どちらを使うべきか? パフォーマンス重視ならBookSleeve、手軽なコストで使いたい ならServiceStack.Redis、というのも今は昔。 ラップが面倒なBookSleeveも、今はCloudStructures(※)が あるのであまり悩むこともなくなった。 ※ https://github.com/neuecc/CloudStructures なぜServiceStack.Redisか? 一番の理由は開発コスト。導入当時はラッパーがなかった。 また、当時はC#4を利用しており、非同期の扱いが手間で、 慣れない非同期を組み込むリスクも踏まえた上での判断。 Npgsqlでの反省も踏まえ更新頻度や実績(利用者数)も参考に。
  40. 40. Redisの活用 - キャッシュ シリアライズ/デシリアライズ Google謹製protocol buffersの.NET実装、protobuf-net。 軽量かつ高速、Googleでの利用実績もあって即決。 同類にMessagePack for CLIがあったが、当時は protobuf-netと比較するとパフォーマンス、実績の点で欠けた (ただし利便性はMessagePackの方が良かった)
  41. 41. Redisの活用 - セッション セッションストアとして利用 カスタムセッションストアプロバイダはAL-Redis(※)を利用。 プロバイダはMSDNを見れば誰でも実装できるが全然速度が 出ないので注意(倍違う)。 ※ https://github.com/angieslist/AL-Redis 他の選択肢 探せばいくつか出てくるが、排他制御にバグがあって高負荷時 に安定して動いてくれないので、Redisを使うならAL-Redisが おすすめ。
  42. 42. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  43. 43. アジェンダ 1. Sansanについて 2. Sansanの構成 1. 2. 3. 4. Webフレームワーク DB(PostgreSQL) キャッシュ/セッション(Redis) インフラ 3. まとめ
  44. 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. 45. ご利用は計画的に 実績には注意 GitHubならWatchやStar、Issuesなどを確認する。 NuGetならDownloadsなども参考になる。 それらを踏まえて、リスクもきちんと評価した上での採用を。 バグは、ある テストは十分に。 できればソースコードも読む。利用する箇所だけだったり、 軽く流し読みするだけでも安心感は違う。
  46. 46. 弊社事例が、皆様の会社での OSS導入の一助になれば幸いです Sansanについて
  47. 47. 最後に • 仲間を募集しています • http://www.sansan.com/recruit/engineer/
  48. 48. ご清聴ありがとうございました。

×