2013.03.16 JAWS DAYS 2013 Day2のTrackC 17:00からのセッションで発表したときの資料です。

1. Meets
Sansan株式会社
間瀬 哲也

2. Profile
■ 間瀬 哲也 (MASE Tetsuya)
● 略歴: 開発 → 運用 → 運用+インフラ
● Sansan株式会社
• リンクナレッジ事業部所属 インフラ担当
• Eight(別事業部)はインフラ助っ人
● AWS歴：1年ちょっと
● 好きなAWSサービス：S3
● Twitter: @matetsu
• ひとりごと
● Facebook: tetsuya.mase
• メシログ

3. Outline
■ Sansan株式会社について
■ EightとAWS
● AWS以前のEight
● AWSへの移行
● 運用
● 課題
■ まとめ
■ 最後に
AWS初級～中級くらいの方を想定した内容となっています。

4. Sansan株式会社
■ 名刺管理
● ビジネス向け: リンクナレッジ
● コンシューマ向け: Eight
■ 2007年6月設立 (6期目)
■ 最近社名表記やロゴを変更

5. リンクナレッジ
■ 「営業を強くする名刺管理」
■ 6年 800社以上
■ AWSではなくオンプレミス

6. Eight
■ 無料で使える名刺管理

7. Eight
 正確にデータ化
オペレーターが手作業で

8. Eight
 人脈を維持&管理
自動でつながる SNS連携

9. EightとAWS
•AWS以前のEight
•AWSへのシステム移行
•移行におけるポイント
•AWSにして助かったこと

10. AWS以前のEight
■ 別のプライベートクラウドサービス
● 限定公開のPrivate β版を提供
● 当時のサービス規模としては安定
書類申請ベース
作業完了まで数営業日
※利用当時の情報です
「今」必要なものが、
「今」手に入らない

11. クラウドサービスの再検討
重要視した点 実績
・他のユーザ
サポート
・評価 スピード
・事業スピードを
・手厚さ
落とさない
・迅速さ
・事業者自身
自由度 可用性
・好きなときに ・高可用な
好きなように セキュリティ システム構成
・自システムの構成
・サービス自体

12. 悩みに悩んだ
国産のとか
今使ってるサー
ビスの別ライン
ナップは？
自分たちのサービスは AWSは？
自分たちで責任をもって
運用するしかないでしょ！
海外のRuby
PaaSは？
インフラできる人
今からオンプ いないけど、IaaS
レ？ で大丈夫？

13. そして
AWS

14. そうと決まればやりましょう！
移行期間は？
2ヶ月！
誰か経験者は？
いません！
じゃあ、設計と
勉強会で探してき かどうするの？
ます！

15. あれ？

16. まずは何をした？
詳しい人を味方につける
サーバーワークスさんに
コンサルを依頼
導入部分やネットワーク設計のベース
EC2以外のサービスの使い方
教わる→やってみる→質問する→やる

17. 次に
触ってみる
まずは手を動かす！
つまづいたら調べる
困ったら #jawsug で聞いてみる
壊れたらまた作ればいい

18. そして
設計通りに作りこむ
時間がないんじゃー！
VPCのセキュリティ設定
インスタンス構築の自動化
バックアップ設定
など

19. 移行(利用)におけるポイント
構成 自動化
セキュリティ 期間

20. ポイント(1): 構成
お作法に従う
■ 基本はMulti-AZ
■ EC2は最小限
■ 自前で作るより使える
サービス
● S3, RDS, Route53,
SES, SQS など
● 仕様（癖？）は知って
おく必要あり

21. ポイント(2): 自動化
(1)サーバセットアップ
■ ベースはAMIで
■ 変動する可能性のある
部分はサーバ構成管理
ツールのChefで
■ web, batch などの
roleを割当てて機能ご
とに異なる設定を適用

22. ポイント(2): 自動化
role[web] Web
Role Server
Role
web Role
web Role
web
web
role[batch]
cook
cook
Batch
cook
book
cook
Server
book
book
ベースAMI book
Image
role[image] Server
※cookbook: 自動構築の手順をまとめたもの

23. ポイント(2): 自動化
(2)アプリケーションデプロイ
■ コマンド一発デプロイ
■ 複数ノードまとめて
■ Chefのroleと連携
● Chefのroleに紐付く
EC2インスタンスリス
トを取得してデプロイ

24. ポイント(2): 自動化
$cap production_web deploy
Role
web Web
Server
web001
web001
web001
web001
capistrano
Web
Server
repository Batch
Server

25. ポイント(3): セキュリティ
細かく制限
■ VPC
● Public/Private
Subnet
● Network ACL
● Security Group
• InもOutも制限
● Management Consoleで
の設定はつらい！
SDKを活用すると楽できる

26. VPCのセキュリティ設定投入

27. VPCのセキュリティ設定投入

28. ポイント(4): 期間
2ヶ月！
■ 実質作業期間3週間
● アプリケーション改修
● デザイン変更
● インフラ移行
● 結合テスト
やればできる

29. AWSにして助かったこと
S3 RDS ELB
Route53 SES

30. S3 (Simple Storage Service)
運用の手間いらず
■ 名刺画像、ログ、バック
アップ用ストレージ
● 簡単に利用できる
● 名刺画像が大量になって
もAmazonさんがよしなに
● 99.999999999%の耐久性
これを自前で作るのは難しい

31. RDS (Relational Database
Service)
リリース1ヶ月前にVPCで利用可能に
■ MySQLを利用
● Multi-AZで可用性アップ
• 料金もUP
● 自動バックアップと自前
バックアップ
• データの消失怖い
運も味方につけた！？

32. ELB (Elastic Load Balancing)
気軽に高可用
■ Webサーバのフロントに
は必ず設置
● 必ずMulti-AZ
● Internal ELBも活用
• 2012年6月から
オンプレミスはこの気軽さはない

33. Route53
手軽なDNSサーバ
■ 簡単に管理
■ 世界中にendpoint
■ ELBやS3との連携
■ SLA100%
面倒な脆弱性対応も必要ない

34. SES (Simple Email Service)
面倒なメールサーバも楽々
■ メール配信
● ユーザ向けメール
● システムメール
● 大量配信もよしなに
● ちゃんと運用してれば、
制限解除もスムーズに
大量配信は素人が迂闊に手を出しちゃいかん！

35. 運用開始！
•トレたま効果
•新機能などの設定追加も楽々
•監視は慣れたツールで
•節約も忘れずに
•見やすさ大事
•新サブシステムリリース
•課題

36. トレたま効果
コマンド一つでスケールアウト
■ 時間帯の予測が可能
■ Knifeコマンドの定型化
● Chefを操作するコマンド
● AutoScaleや
CloudFormationは使っ
ていないんですよね
通常運用時の10倍アクセスも難なく対応

37. 新機能などの設定追加も楽々
Chefにおまかせ
■ まとめて適用
■ 事前にしっかりテスト
● 検証用のStaging環境
● Environmentを利用
■ 開発チームと情報連携
■ 今ならOpsWorks？
新機能もスピーディに提供

38. 監視は慣れたツールで
運用の肝
■ Nagios+CloudWatch
■ CloudForecast
+ CloudWatch
■ 監視にもfluentdも活用
したい
● ログ集約では使ってる
APIを使って簡単にカスタマイズ

39. 節約も忘れずに
Time Is Money
■ ReservedInstance
■ CloudWatchで料金監視
■ 開発環境は節約徹底
● 使わないときは停止
● 使わないEIPはリリース
● 不要なEBSがないか
無駄はダメ

40. 見やすさ大事
設定Viewer
■ VPCの設定Viewer
● 特にNetwork ACLと
Security Groups
• Inとoutを並べて
● Route Table
• RoutesとAssociationsを
同時に
Management Consoleが見やすければ。。

41. 設定Viewer(1)

42. 設定Viewer(2)

43. つい先週リリース
SWF(ワークフロー)を使ったシステム
■ 名刺データ入力システム
● 入力の各工程を小さな
サービスに分割
● 疎結合な仕組みを実現
● 優先度設定で苦労
• SWFでは未実装
＃ヤマンさん、色々とご対応ありがとうございます！

44. SWFの利用イメージ(1)
入力工程
A→B→C→D→E→F
A B C D E F
各工程(の処理)を小さく分割して実装
A B C D E F
Service Service Service Service Service Service
Worker Worker Worker Worker Worker Worker

45. SWFの利用イメージ(2)
名刺の取込
Decider
ワークフローを (ワークフローの管理、
開始 処理のルーティング)
Startar
Get Return
SWF
domain
Workflow
Workflow Executions (‘この’名刺のデータ化)
Activity A ・・・ Activity E Activity F
Get
Worker
(タスクを ・・・・・・
処理) Return
Operators

46. SWFの利用イメージ(3)
名刺の取込
Decider
場合によっては、不要な処理をスキップ
Startar
Get Return
SWF
domain
Workflow
Workflow Executions (‘この’名刺のデータ化)
Activity A ・・・ Activity E Activity F
Get
Worker
・・・・・・
Return
Operators

47. 事業の未来を担うシステム
(となるか？)
拡張性 安さ
正確性 早さ

48. 課題
■ リリース時からインフラにあまり手を入
れられていない
パフォーマンスの改善
とくにMySQLまわり
ログの活用
EMRで解析、監視など
さらなる自動化
人の手は極力排除、新たな一手を

49. まとめ
AWSをフル活用
■ 便利でスケーラブルなサービスが多い
● 活用して運用コストをダウン
■ 自分たちの事業に本当に必要なところに
注力する

50. 最後に
ぜひ使って
みてください！

51. おまけ
来たれ！
■ Eight / Sansan株式会社ではエンジニア
を募集しています。
● 特にインフラ / オペレーションエンジニア
の方！
● Rubyエンジニアも！

52. 10万人が使う名刺管理アプリ