「サーバにログインしない・させないサービス運用」講演メモ (AWS Summit Tokyo 2015) #AWSSummit

メモった。間違い等あるかもしれませんが、その場合はごめんなさい。

Gunosy

• 2011.09リリース
• 現在900万DL突破
• エンジニアは現在26名
  • 2014.11は16名、2013.11は7名、2012.11は4名
  • クライアント+QAは5名、Web+APIまわりは5名、インフラは1名とかとか

Gunosyの開発

• API: Golang
• パートナー・広告主への管理画面: Rails
• バッチ・内部向け: Django or Python
• バージョン管理: GitHub
• 構成管理・デプロイ: Chef (+OpsWorks)

開発の特徴

• 小さい単位で作ってすぐ捨てる
• マイクロサービス的な
• 機能が増えすぎたら分割
• メンテするよりリプレース

サーバにログインされて困る事

• 信頼できないビルド・デプロイ
  • 開発者の手元でビルドすると、どの断面なのかわからずトラッキングできない
  • プロダクションに上がっているものが信用できない、ステージングも本当にテストしたい断面のもの？
• 勝手に加えられる変更
  • 勝手に追加されるパッケージ
    • サーバ追加/リプレースしようとすると動かない
  • 勝手に変更されるcrontab
    • コメントアウトしたの誰？なぜ？
• 以前はChefを使っていた
  • サーバとレシピの間に乖離がある
  • レシピを追随させる必要がある

アプリケーションのデプロイは信頼できるものである必要がある

• 信頼できないデプロイ
  • 事故のリスク
  • 手戻りの発生
  • エンジニアの時間的・精神的負担

バージョン管理・CIツール・デプロイツールをそれぞれを導入すればよいというものではない。
全てを統合した一連のワークフローを作る事が大事。

GitHubを中心とした開発・デプロイフロー

• Service Hookを利用し、各サービスを連携
  • GitHub, CircleCI, AWS OpsWorks
• 各ブランチをマージする度に自動でビルド・テスト・デプロイ
  • 見える化、効率化、事故の削減
• デプロイしたければPull Requestを作る
  • Pull Request Driven Deploy
• OpsWorksでもデプロイ履歴は追える

どうしてもつきものなのが調査

サーバにログインして調べますか？
ブラウザから全てのサーバログを見られるように

• ミドルウェアログ収集
  • papertrail
• アプリケーションログ収集
  • airbrake (errbit)
  • kibana

papertrailを使って、サーバにログインがあればhipchatに流れるようにしたりとか

---

まとめ

• Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)