社内勉強会用

1. システム運用を振り返り
伝えたいこと
株式会社CyberZ 黒木亮太
2016/04/13

2. 自己紹介
• 名前：黒木 亮太
• 2012年1月にサイバーエージェントに入社
– Patriot
– ニュースSNSサービス（BtoC）
– 電子書籍サービス（BtoC）
• 三度の飯も、息子も好き

3. ※注意事項※
これから話す内容に、悪いという概念はありま
せん。
あくまで、伝えたい事を具体的にするための例
としてあげています。

4. 1. 拡張性は大事！

5. 例1） 内製化プロジェクト
Aさん：
「BtoCサービスをやってみたいです」
偉い人：
「今、内製化を進めようとしているサービスが丁度あ
るから、youやっちゃいなよ」

6. 例1） 内製化プロジェクト
■背景
• WordPressで作成されていて、DBが依存している
• HTMLファイルキャッシュを作成していて、更新があ
る度に再作成
• WebサーバとDBサーバがセット構成なので、Web
サーバが増えるともれなくDBサーバも増える

7. 例1） 内製化プロジェクト
■背景
• WordPressで作成
• HTMLファイルキャッシュを作成していて、更新があ
る度に再作成
• WebサーバとDBサーバがセット構成なので、Web
サーバが増えるともれなくDBサーバも増える
システム限界
が訪れる

8. 例1） 内製化プロジェクト
■結果
• WordPressを剥がした上で、フルスクラッチでリプレ
イス
• すでに動作しているサービスを全く同じように構築
する必要があるため、新規開発よりも難易度が上
がってしまう
■教訓
サービスの目標数値（DAUなど）を視野に入れたシス
テム設計をする

9. 例2） OpenStack SwiI
■背景
• 数TBの画像データを格納する
• 1コンテナあたりの容量上限はないので、1コ
ンテナにすべてぶち込む

10. 例2） OpenStack SwiI
■背景
• 数TBの画像データを格納する
• 1コンテナあたりの容量上限はないので、1コ
ンテナにすべてぶち込む
性能限界
が訪れる

11. 例2） OpenStack SwiI
■結果
• 容量上限はないが、性能面で劣化が見られるように
なったため、複数コンテナに格納するように改修
• 既存データは常にreadが発生するため、データ移行
の難易度が上がる
■教訓
想定容量の場合での性能をきちんと把握する

12. 2. 技術選定は大事！

13. 例3） ORマッパー
偉い人：
「ORマッパーは共通ライブラリがあるからそれを使っ
てね。あと、データストアはHbaseを使ってね。」
Bさん：
「・・・はい」

14. 例3） ORマッパー
■背景
• javaオブジェクトをjsonデータとして永続化す
るORマッパー
• 特定のフレームワークやデータストア
（Hbase,MySQLなど）に依存せずに利用できる

15. 例3） ORマッパー
■背景
• javaオブジェクトをjsonデータとして永続化す
るORマッパー
• 特定のフレームワークやデータストア
（Hbase,MySQLなど）に依存せずに利用できる システム開発工数
が破綻

16. 例3） ORマッパー
■結果
• データを保存しよう
– auto_incrementなどないので、アプリ側で実装
– トランザクションもないので、アプリ側でロックを実装
• データ構造を変えよう
– 新たなindeｘを作成するには、データを入れなおさないといけない
• データの確認をしよう
– Jsonなので用意にデータが見れない
■教訓
共通化も大事な要素だが、運用がイメージ出来ないものを採用して
はいけない

17. 3. リカバリを考慮するのは大事！

18. 例4） 購入処理
■背景
購入処理をする際に、
plaSormシステム：課金処理
agencyシステム：購入通知処理
で、2つのシステム間での連携が必要。

19. 例4） 購入処理

20. 例4） 購入処理

21. 例4） 購入処理
あれ、、
購入キャンセル
が出来ない(´・ω・｀)

22. 例4） 購入処理
■結果
• それぞれ違うシステムのため、トランザクションを
はれない
• 状況が発生した場合は、運用で返金などを行う
必要が出てしまった
■教訓
APIを提供する際は、処理が失敗した場合のリカバ
リも考えて設計をする

23. おわり