Sansan のインフラ概要

2016/7/28 に開催された Sansan×gloops インフラ合同勉強会で発表したスライドです

compass -> http://connpass.com/event/33442/

Transcript

1. Sansan インフラの概要
2. 自己紹介 なまえ ：岩下訓 (いわしたさとし) しょぞく : Sansan 事業部開発部 弱小ブログ : http://rriifftt.hatenablog.com/ けいれき : → バーテンダーしたり DJ したり → NW エンジニア(SIer) → Sansan そろそろ 5 年目
3. Sansan のインフラエンジニア • 法人向けサービス Sansan • 個人向けサービス Eight • 名刺をデータ化するバックエンド Operation • 社内インフラ それぞれの部門に、それぞれのインフラエンジニア
4. 本日は 法人向けサービス Sansan のお話です
5. Sansan インフラのお仕事 • サーバの設計、構築 • システム運用、改善 • インシデント対応 • セキュリティへの対応 • 費用のこと ＞ 事業欲求、優先度に応じて柔軟に対応 ＞ インフラとしてやれることはなんでもやる (なんでもやるとは言っていない)
6. • 日々の運用 ◦ グラフ みたり、ログ見たり、 alert 対応したり、証明書更新したり • インフラのタスク ◦ OS バージョンアップしたり、 WAF 導入したり • プロジェクトへの参画 ◦ ログ運用改善とか、DB スケールアウトとか ＞ 複数並行は日常的 お仕事の進め方
7. Sansan インフラ構成の超概要 • オンプレ期の構成を改善していくスタイル • 目新しいことは特にやってません
8. Web / API • IIS 8.5 • .NET Framework 4.5.2 ( 4.6.1 に移行中) • chef ◦ powershell (not dsc) ごりごり ◦ chocolatey • NewRelic • fluentd for Windows • AD ドメインへの参加
9. Batch • IIS 以外は Web / API とほぼ同じ構成 • 70 以上のタスクが稼働 • タスクスケジューラで頑張っている ◦ つらい ◦ dc/os に期待
10. DB • PostgreSQL 9.3 ◦ 全てのデータをオンメモリで保持 ◦ 自前の水平分散アーキテクチャ ▪ 20 強の DB インスタンスが稼働 ◦ pgpool + heartbeat を用いたクラスタリング ◦ Streaming Replication (非同期) ◦ chef ▪ クラスタ構成までやるので割と複雑 ◦ メンテナンス用途に pg_reorg 活用 ◦ LDAP 認証
11. Cache • Redis 2.6 ◦ Session や検索結果などをキャッシュ ◦ 永続化を前提としないデータストアとして利用 ◦ 自前で冗長化 ▪ shellscript ◦ 絶賛 3.2.1 への移行作業中
12. monitoring • icinga ◦ 死活監視 / サービス監視 ◦ 自前のプラグインが多数稼働中 ▪ bash / python / node • munin ◦ リソース監視 ◦ そろそろ重たい ＞ mackerel or zabbix への移行を計画中
13. 少しずつ複雑化するインフラ • Windows : 40% / Linux : 60% の混在環境 • shellscript / python / powershell • 機能増加と役割増加 • スケールアウトの必要性 ＞ システムの課題が浮き彫りになっていく
14. 様々な課題 • 使われている技術が散らかる • 手順書の再利用が大変 • 実際の状況を把握することが困難 • Windows のことが好きなインフラエンジニアがいない(当社比) ＞ インフラの構築、運用改善にスピードがでない
15. ということで (もはや、やっていないと人間として扱われない風潮にも後押しされ ) Infrastructure as Code を推進 • chef • serverspec ＞ これらを gitlab で管理
16. サーバ構築の流れ • 実装 ◦ chef / bash / powershell / python / 各種 configuration などなど • レビュー • 各環境(develop/staging/production)のブランチにマージ • chef でプロビジョニング • serverspec でテスト
17. chef • chef-server / chef-client / knife [ssh|winrm] を活用 ◦ 構築だけでなく日々の運用でも活躍 ◦ 自動 PULL まではやっていない (事故がこわい) • Windows / Linux 混在に適しているとされているが ◦ OS の違いを吸収させるのがしんどくなったのでリポジトリわけた • 30 role / 200 node を管理 • 基本的に cookbook は自前で書く
18. serverspec • 構築したインスタンスのテストを実施 • リズム良く書けて、何を気にしているかがわかる • カバー率はそこそこ • テストファーストまではまだまだ • 他ツールとの連携を強化したい ◦ CI だけでなく監視組み込むとか
19. Infrastructure as Code をがんばってみて 基本的にいいことばかりだった • サーバ構築の時間短縮 • コード化されたことで見通しがよくなった • 高い再利用性 • 引き継ぎコストの減少
20. Infrastructure as Code で幸せになった とは言い切れず、よくあるようなつらみもあります • ツールそのものとツールの周辺言語の学習コストが高い • 役割が異なるリポジトリの乱立
21. 先輩 Said... 「人間は 2 種類しか存在しない。オシャレか、オシャレじゃないかである」
22. オシャレになりたい 課題はたくさん • インフラの CI • テストの充実 • イケてるデプロイ • オートスケール 少しずつ進めています
23. まとめ インフラはやることいっぱい
24. ご清聴ありがとうございました