今日は、Developers Summit 2014
Cassandra Summit JPN 2014 にいってきた（午前編） - #garagekidztweetz
今回は、たまたまわたしが参加してきたセッションが、みごとに Process(DevOps) の #devsumiB のトラックと IaaS の #devsumiE の2つにキレイにわかれていたので、そのそれぞれのトラックで前後編をわけています。
ちなみにわたしが今回、参加してきたのは以下の 7 セッションです。
- 【13-B-1】サーバプロビジョニングのこれまでとこれから 宮下 剛輔氏 〔paperboy&co.〕
- 【13-B-2】グリーにおけるChef導入事例 ～既存の資産を活かし新しい技術を導入する～ 荒井 良太氏 〔グリー〕
- 【13-B-L】テスト自動化を見直そう！自動化への投資が開発チームをクリエイティブにする 安竹 由起夫氏 〔コベリティジャパン〕
- 【13-B-3】社内システムの構造と設計、実装のはなし 田籠 聡氏 〔LINE〕
- 【13-E-4】「さくらのクラウド」開発と運用、裏話的な何か 鷲北 賢氏 〔さくらインターネット〕
- 【13-E-5】Stormで実現するビッグデータのリアルタイム処理プラットフォーム 鈴木 貴典氏 〔Acroquest Technology〕
- 【13-E-6】～非常事態で慌てないために～自在にスケールするクラウド・インフラを作るためのベスト・プラクティス Phil Jackson氏 〔SoftLayer〕
個人的には、以下の 2 セッションに参加できただけで、今回のデブサミにでた甲斐がありました。
- 【13-B-1】サーバプロビジョニングのこれまでとこれから 宮下 剛輔氏 〔paperboy&co.〕
- 【13-B-3】社内システムの構造と設計、実装のはなし 田籠 聡氏 〔LINE〕
話題の Immutable Infrastructure の話などを最前線にいるエンジニアの方から聞けて大変ためになりました。
では、以降よりが前編 #devsumiB のトラックでわたしがとってきたメモです。 （あとですこしづつリンク等を足していくつもりです）
- 会場 B は和田卓人氏の挨拶で開演！
- 今年のテーマはストーリー。
- devsumi は交差点のような場所。
- そのときどきのテーマに目黒雅叙園で出会う場。
- インフラ技術の自動化は去年のバズワードのひとつだった。
- immutable infra の考え方。サーバの環境設定をテストすることを可能にした serverspec など
10:00～10:45 【13-B-1】サーバプロビジョニングのこれまでとこれから 宮下 剛輔氏 〔paperboy&co.〕
スライドはこちら
- 2013年インフラ系の流れが大きく変わった
- 氏のブログエントリにも数多くポストしたらしい
＊＊＊＊＊
- インフラという言葉の範囲自体がそもそもとてもひろい
- OS 以上をすべてインフラというようにすらなってきている
- アプリケーションを動かすためのインフラというようになってきている
＊＊＊＊＊
- paperboy&co. ロリポップ、テクニカルマネージャ
- @gosukenator
- github.com/mizzy
- mizzy.org
＊＊＊＊＊
- Puppet
- gihyo.jp で連載
- SW Design で連載
- serverspec の開発
＊＊＊＊＊
サーバープロビジョニングとは？
- Velocity Conf からの引用
- 3つのレイア
- Orchestration: Application Service Orchestration : Capistrano, Fabric
- Configuration: System Configuration : Puppet, Chef
- Bootstrapping: Cloud or VM image launch / OS Install : EC2
＊＊＊
- Bootstrapping 言葉だけながした
＊＊＊
- Configuration
- サーバーコンフィギュレーションはここをさすことが多い
- 手動インストール、設定
- Shellscript
- いわゆる構成管理ツール CFEngine, Puppet, Chef, Ansible etc...
- 会場の半分くらいがこれらを使った経験あり、 Chef が圧倒的
＊＊＊
- Orchestration
- ここの概念はわかりにくい
- インフラの新しい概念がはいってきている
- あとで詳しく
＊＊＊
- ここまでのまとめ
- サーバプロビジョニングには3つのレイアがある
＊＊＊＊＊
Infrastructure as Code
- インフラのコード化、字面どおり
- この言葉がではじめたのは 2008 くらい（明確に誰がいったかは不明？）
- Chef の開発者？
- 2005 にでた Puppet が開発されたのが駆け出しではないか
- Puppet: Next-Generation Configuration Management
- 源流は 1993 の CFEngine
＊＊＊
- CFEngineより提唱された構成管理ツールの要件
- 宣言的：何をしたいかであってどうするかではない
- 抽象化：あなたの代わりに詳細の面倒をみてくれる
- 冪等性 : 必要なときだけ実行する。ある状態になっていたら何もしない
- 収束化：放っておけばどうにかなる
＊＊＊
- Infrastracrture as Code とは？ (photo)
- ソースコードリポジトリ
- アプリケーションのバックアップ
- サーバリソース
- これからのビジネスをゼロから再構築できるようにすること
- サーバ構築・運用におけるワークフローに変革をもたらすもの
＊＊＊
- Infrastructure as Code から Test-Driven Infrastructure へ
- テスト駆動インフラ
- テスト駆動インフラはとくに Chef 界隈で盛り上がっている
- Test-Driven Infra with Chef という書籍
- Test Ketchen という OSS
- コードでインフラを記述を更に推し進めたのが Chef (Puppet よりもさらに)
- Chef は Ruby そのものなので Ruby でできることはなんでもできる
- より developer が親しみやすいインフラになってきている
＊＊＊
- とはいえ、みんなが Chef を使っているわけではない
- ここで serverspec の紹介
- Test Kitchen とも連携して使える
- WebDB Press の 78 号に載ってるお
- hbstudy#45
＊＊＊
- テスト駆動インフラが駆動するのはインフラそのものではなくインフラを記述したコードを書くこと
- リファクタリング対象はインフラの状態を記述したコード、インフラそのものではない
- インフラの状態をテストするために severspec をつくったわけではない
- インフラの状態を記述したコードをテストするためのツール
＊＊＊＊＊
TDD/Infra CI/Github Flow
- インフラのコード化とテストの自動化がときたら次は CI
- Jenkins (serverspec でかいて Jenkins でテストをする
- Wercker
＊＊＊
- Github Flow によるインフラワークフロー
- レビューとテストを裏側で走らせる
- Puppet マニフェストのテストの例
＊＊＊
- ここまでのまとめ (photo)
- Infrastructure as a code
- インフラをコードで記述する
- テスト稼働インフラ、インフラ CI 、GitHub Flow
- Infrastructure as a code
＊＊＊＊＊
Immutable Infrastructure (Disposable Components)
- Immutable よりも Disposable のほうが重要（禿同）
- 動いてるサーバには変更を加えない
- 全く新しいサーバを構築してロードバランサ等で切り替え
- 成功したらもとのサーバは「破棄」
- 失敗したらもとに戻す
＊＊＊
- 言葉がでてきたのは 2013 だが、もっと前から
- Blue-Green Deployment という名前でもともと手法として存在していた
- EC2 のような IaaS でこのようなことが容易に。
＊＊＊
- Immutable/Disposable によるメリット
- 変更に伴うトラブルが起こりにくい
- 継続的改善がしやすい
＊＊＊
- 設計へのよい影響
- Heroku でだしている言葉
- The Twelve-Factor App
- IX. Disposability
- Disposable にすることでより堅牢になる
＊＊＊
- Disposable であることで
- Chef や Puppet のようなツールがよりシンプルになる
- （それらがもっている複雑な面、冪等性などの制約からくる複雑さ）
- Shell で十分ってこともある（禿同）
＊＊＊
- Immutable にできないところはどうするのか？
- それはケース・バイ・ケース
- RDBMS, 画像ストレージいろいろなケースがあるので一概にいえない
- 外部の RDS などにまかせてしまうというのも一手だろう
＊＊＊
- Container Base Deployment
- Immutable Infra の応用的なもの
- コンテナ？＝単機能・軽量な VM (とここでは便宜上に定義する)
- 新しく作ったコンテナをアップロードしてまるごと置き換える
- 例えば、 Docker
- ポータブルなのでローカル環境と本番環境で同じ環境がつかえる
- ローカルで十分にテストしたあとでそのまま本番にデプロイできるというメリット
- テスト駆動→CI→デプロイが可能に
＊＊＊
- コンテナのその他のメリット
- サーバ部品のコンポーネント化
- コンポーネント化が進むことで部分的な入れ替えも容易に
- 単機能化することでテスタビリティも向上
- IaaS 上でなくても Blue-Green Deployment もできる
- Mesos/YARN 等との組み合わせで自動的なリソース配置最適化みたいなことも試みられはじめている
＊＊＊＊＊
Orchestration
- Configuration＝単一のサーバで完結するもの
- Orchestration=複数のサーバが関連するもの
- と考えるとわかりやすいのではないか
＊＊＊
- その実例 photo
- 単一のサーバで完結
- Apache や Nginx
- 複数のサーバが関連するもの
- ロードバランサへのノードの追加
- Munin や Nagios へのノード追加
- アプリケーションのデプロイ
- 単一のサーバで完結
＊＊＊
- 旧来の Orchestration は Immutable Infra の前提はなかった
- サーバの増減は頻繁ではない
- Command＆Control
＊＊＊
- 新しい Orchestration
- Immutable/Disposable な世界
- サーバの増減頻繁
- Autonomy/ 自律協調
＊＊＊
- それを実現する一例としての Serf
- その役割 photo
- ノードのクラスタリング
- ゴシッププロトコルベース
- イベントプロパゲーション
- その役割 photo
＊＊＊
- Serf でやれること、やるべきことを Orchestration ととらえるとわかりやすいのではないか
＊＊＊＊＊
まとめ：サーバプロビジョニングのこれから
- テスト駆動でインフラ構築
- Bootstrapping に Docker
- Puppet や Chef よりもシンプルなツールに回帰するかも？
- テストに serverspec
- インフラ CI で継続的インフラテスト
- Jenkins, Wercker, CircleCI, Drone etc...
＊＊＊＊＊
参考：
11:05～11:50 【13-B-2】グリーにおけるChef導入事例 ～既存の資産を活かし新しい技術を導入する～ 荒井 良太氏 〔グリー〕
スライドはこちら
- Chef の本番環境導入事例
- @ryot_a_rai
- 社内の Advent Calendar の内容 +alpha
＊＊＊＊＊
- 質問 ** Chef 知ってる、使ったことはあるけど、仕事で使ってるとなると少ない
＊＊＊＊＊
- Chef
- サーバの構築や設定更新を自動化するツール
- サーバのあるべき姿を Ruby で書いておくとその姿にセットアップしてくれる
- 冪等性が重要（何度実行しても、同じサーバになる）/ Mutable Infra と相性良し
- Chef 社の OSS
＊＊＊＊＊
- コードの例 photo
＊＊＊＊＊
導入背景
- よくある光景として、製品を作っている人と、運用している人は分かれていた
- 運用担当者が秘伝の手順書のようなもので手動でサーバ構築していた
- もう一台くださいといわれるとまた手作業するの繰り返し
- ルーチンワークなので非効率だった
- それを自動化して効率化させようという背景だった
＊＊＊
- 非効率の解消→効率化
- オペミスのリスク回避→安定運用
- リードタイム→サーバのデリバリーを速くする
＊＊＊＊＊
Before Chef
- 既存のインフラでどんなことをしていたのか？
- Debian パッケージを手動でインストールしてた
- 設定ファイルはスクリプトで生成（ debian パッケージ内のスクリプト、 shell スクリプトで複雑だった）
- 設定値もパッケージ内、もしくはサーバ管理システム内での管理
＊＊＊
- パッケージを更新、パッケージを apt-get install
- 設定値をサーバ管理システムから引き出して、スクリプトでサーバに設定
＊＊＊
- サーバ管理システム
- 社内のサーバ情報を一元管理
- 運用スクリプト・ツールが依存
- Debian パッケージが依存
＊＊＊＊＊
Chef 導入方針
- 新規のサーバを Chef で構築していく（構築済みサーバでは Chef の導入はしなかった）
- 毀損のサーバ管理システムを利用する
- 毀損のツールスクリプトが動く状態で移行する
＊＊＊＊＊
Chef の導入
＊＊＊
- Chef の概要→図解
- クックブック、ロール、属性
- Chef Solo と Chef Server どっちを利用しようか？という議論
- 結果的には Chef Solo を使うことにした
＊＊＊
- Chef Server をやめた理由
- SPOF→有償では保証されるが
- サーバ管理が重複する（サーバ管理システムを既存でもっていたから）
- 運用→多数の SW を使っている、 Erlang を使える人がいない (Chef Server は Erlang)
＊＊＊
- Chef Solo + alpha にすることにした
- 図解
- サーバ管理システムと Chef Solo の間を Chef Bridge (内製) と GREE Chef Client (内製: Chef Solo の Wrapper) でつないだ
＊＊＊
- Chef Bridge
- 内製の Chef Server のようなもの
- HTTP API
- サーバ管理システムへの問い合わせを行う
＊＊＊
- GREE Chef Client
- Chef Bridge から必要な物を取得、ノード属性、クックブック、ロール
＊＊＊
- Chef Server VS. Chef Bridge
- 冗長性、運用しやすさ、既存環境との親和性で優位
- API では不利
＊＊＊＊＊
CHef でつくる必要がある者
- クックブック、ロール、属性
＊＊＊
- クックブックに関しては
- 基本的に自社でクックブックを作成している
- コミュニティクックブックはあまり利用していない
＊＊＊
- Chef 入門
- Chef 使いを育てることからはじめないといけない
- 学習コストが高い
＊＊＊
- GREE ではどうしているか
- まずは入門 Chef Solo を自費で買え
- 初心者 Chef アンチパターン読ませる by Julian Dunn
- 社内チュートリアルをこなしてもらう
- 公式ドキュメント読め
＊＊＊
- クックブックの開発
- テストを書く
- serverspec/Test Kitchen
- chefspec
- Foodcritic : クックブックの Lint ツール。ルールに従っていないと警告が出る。
- GitHub / Pull Request
- Master に直接 push したりしない
- Pull Request 上で議論
- CI
- GitHub に push
- Jenkins がテスト
- Jenkins がデプロイ
- ふつーのことをふつーにやっている
＊＊＊＊＊
*そもそもなぜテストを書くのか * TDD的な開発の後押し * リグレッションを防ぐ * ドキュメントがわり * 本番サーバの構築テスト
＊＊＊＊＊
- いくつか serverspec と Test Kitchen をつかってハマった問題
- Jenkins Server につながらなくなった
- 原因：NWのルーティングが変わった
- Mutable Infra 問題
- テストに時間がかかる問題
＊＊＊＊＊
運用していくと…
- 構築ログがみたいということがでてくる
- Chef 後は
- 実行ログは DB に自動保存
- Chef の Report Handler
- fluentd -> MongoDB
- Chef の Report Handler
＊＊＊＊＊
まとめ
GREE における Chef 導入の実践プラクティスを紹介しました。
＊＊＊＊＊
参考：
- 2014/02/13 デブサミ2014【13-B-2】グリーにおけるChef導入事例 ～既存の資産を活かし新しい技術を導入する～ #devsumiB - Togetterまとめ
- デブサミ2014「グリーにおけるChef導入事例」講演メモ #devsumi - 元RX-7乗りの適当な日々
12:20～12:50 【13-B-L】テスト自動化を見直そう！自動化への投資が開発チームをクリエイティブにする 安竹 由起夫氏 〔コベリティジャパン〕
- ランチセッションなので気楽なムードでってことで。
＊＊＊＊＊
- 静的解析をコアとした製品を売っているのがコベリティ
＊＊＊＊＊
テスト自動化の事例、気付き
- Coverity Connect の自動テストの例
- 画面系、ユニットテスト、コードレビューの自動化などなど
＊＊＊＊＊
5. 本能に自動化が解決策？？
- 同じテストを4回まわしたらコスト的にペイできる
- 担当者が決まらないと 30% 遅い - firefox 上で見つかったバグが解決されるまでにかかる時間
- 各修正プロセスに要する時間
- 人がアサインされないままに直すってことがそのときにはあった
- 人がアサインされないと 10 日、人がアサインされていると 7 日
- 新規不具合は優先的に対処 (Linux)
- なるべく客観的にデータをみる
- ほっとかれ時間をみてみる
- コベリティの製品リリースプロセス
- Agile
- Scrum
- JIRA
- Bugzilla *（自動化の）明確な必要性
- 6ヶ月のリリースサイクル
- サポートプラットフォームの多さ
- Jenkins 上のビルドは各プラットフォームに分散
＊＊＊＊＊
4. 担当者のスキルセットは正しいか？
- コベリティ、最初は失敗だった。自動化のスクリプトが書けない。スキルセットのミスマッチ。
- 抜本的な改革は人に対して行った - アウトソースはやめた
- スキルセットの変更
- テスト自動化に焦点をあてたスキルセット
＊＊＊＊＊
3. コードカバレッジの罠
- コベリティ静的解析エンジン : コールグラフ + 条件分岐
- 全パス、全自動、コードシュミレーションをする、がコベリティをかけたから C1 をすべてカバーするわけではない
- コードカバレッジは 100% でもバグはある
- テストをしなくていいわけではない
＊＊＊＊＊
2. 優先度を設定しているか？
- どこからテストするかといったときに闇雲にテストすればいいというわけではない
- どれくらいテストをしてどれくらいバグがみつかっているかというグラフ
- 一番効率がよく一番バグがみつかるところにテストを行う
＊＊＊＊＊
1. クリーンなコードになってる？
- 結合レベルでのクリーン
- コードレビューの改善（自社製品をつかって） photo
＊＊＊＊＊
様々な静的解析が自動化を高める
- Coverity Issue Management Workflow
＊＊＊＊＊
参考：
13:05～13:50 【13-B-3】社内システムの構造と設計、実装のはなし 田籠 聡氏 〔LINE〕
スライドはこちら
- LINE で社内システムをつくるためになにをしているか、といった話
- 細かいものをつくったり、とじたりじつは頻繁にしている
＊＊＊＊＊
DevOps の話？
- このトラックのテーマは Devops だが、その言葉、あまりすきじゃないｗ
- Dev of Ops, by Ops for Ops
＊＊＊＊＊
- 今日のいいたいこと
- 社内システムほど、他システムとの連携を考えよう
- 社内システムでは JSON API を使おう
- 実装は必要なところから必要なだけやろう
＊＊＊＊＊
- Web 2.0
- マッシュアップ全盛期 - どこをみてもマッシュアップな時期
- OAuth流行、支配的に
- WebAPI 制限
- GoogleApps
- むかしほど API つかえばいいよねという楽観的なことではなくなってきている
- Open Web API
- トラフィック、レスポンスタイム (太平洋の横断にかかる時間)
- コストは誰が払うという問題
- 互換性の問題 (facebook や twitter の API がコロコロ変わる)
- 開発者なんでやりなおしたくなるときあるよね
- 社内システム: Closed Web
- Web でないこともあるだろうけど、ここではそういうことにしよう
- 機能 > 性能
- 性能が第一になることはめったにない
- Long Life Cycle
- あれば仕事が回っちゃう系のシステムっていうのがある（問題点がわかっていても）
- Target User は自分
- ドッグフードを作る人が第一の利用者ではないという問題
- 作る人が、使う人のことを常に考えて作るべきものが社内システム * やることたくさん
- プロとコロル変換、データ蓄積、資産管理、可視化、認証などなど
＊＊＊＊＊
で、何が問題なんだっけ？
- 情報と権限が分断されている
- 権限を管理する人が情報を管理する人と別という問題
- 情報と機能の冗長化
- ムダという意味の冗長化
- 社内がシングルサインオンじゃない
- ムダという意味の冗長化
- UX の欠如
- 社内システムほどいいかげんなものはない
- 自動化の障壁
- 自動化を考えずにつくられてしまった社内システムはそれそのものが自動化の障壁になってしまう
- 全部入り：アップデート不可能
- 全部作りなおすしかないという状態
- 社内システム連携？
どうするんじゃ
- DB を直接見る、しかしこれは完全な密結合になってしまう
- SOAP
- なかったコトにしたい感じのアレ
- SOA!
- SW 高い、認証どうすんだ、いろいろありますね
- RPC Protocols
- Protocol Buffer, Thrift, XML-RPC, MessagePack-RPC, ....
- 最初から組み込む必要がある
- 社内システム連携: make it simple!
- SOA がうまくいったというのは聞いたことない
- Simple にいくほうこうにたおそう
＊＊＊＊＊
シンプルにしていくために
- 権限
- 分断を最小限にしよう
- 参照に関してはフラットにやろうよ
- 機能
- 情報は複数の参照方法を
- ブラウザで見る (JIRA, Confluenece, Github Enterprise...)
- 参照する側がその API を直で呼び出せるようにしておく (AngularJS)
- 情報は複数の参照方法を
- モジュール化
- 単機能システムを連携させる
- アップデートが容易な状態を保つ
＊＊＊＊＊
社内システムほど他のシステムとの連携を考えよう
- 機能を API として公開しよう
- API の互換性保持だけを考えればよくなるということ
＊＊＊＊＊
- Closed Web API
- トラフィック、レスポンスタイムは問題にならない（よっぽどなことがないかぎり）
- コストは誰が払う？
- 会社が払う
- 互換性
- 疎結合性を確保する
- API 互換性
4 つの要素
- プロトコル
- データ構造 - ドキュメントに頼るようにはしたくないよね
- 意味の一貫性 - API の裏側の動き
- クライアント要件の不変性／普遍性
- Windows でないと Excel でないと動きませんでは困りますよね、
- 一度採用したらそうそう変わらないものを選ぶ
＊＊＊＊＊
Protocols of Closed Web
- Thrift, Protocol Buffers
- FTP, RSH, SSH
- HTTP - 再優先で選んでいいのではないか
- SOAL, XML-RPC,...
- JSON - これが一番いいと思ってる
＊＊＊＊＊
長期運用をする
- 多くの組織では document に依存する、が、 document は陳腐化する
- document に頼らないためには、自分の目で直に見ること
- そのときに一番、使い勝手がいいのが、 JSON だという個人的見解
- 見た目の分かりやすさ大事
- 長期運用するということは、きちんとアップデートするということ
- アップデータの容易さを担保するために
- データフォーマットを選ぶ、プロトコルを選ぶ
- テストの容易さ
- curl is great
- コマンドたたいて一発で通信ができることを確認できるプロトコルは少ない (http はやはり素晴らしい)
- 百聞は一見に如かず
- 1 times curl >>> 100 pages docs
- ease to try >>> performance
- loosely coupled >>> strict protocol
＊＊＊＊＊
社内システムでは HTTP の JSON API を使おう
- 動くこと何より大事
- ドキュメント大事？
- 疎結合でまず動くことをまず第一優先しよう
- こんなこともあろうかと、と作ってる時間もったいない
- 必要のないものはつくらない
- いまほしい機能をつくる！
- 優先度ハック
- 実装が楽な API を使おう
- 機能を切り刻む
- 疎結合を実現
- 修正単位を最小化する
- 必要なところだけに手をいれればよくなる
- 逆優先度ハック
- 切り刻まれた細かい機能追加タスク
- 細かいタスクをつけたしていく
- 柔軟な優先度の変更
- 今やらないならあとでやればいいのでは？
- だっていつでもできるじゃない？
- 細かい問題におとしておけば、あとで必要なときに簡単にできるようになっている
- あとでやればいいなら、今後何が必要かを洗い出しておく
- 将来の要件定義は難しい
- だから後回しにしようよ
- 積極的にサボりながら、必要なことだけをやろう
- 切り刻まれた細かい機能追加タスク
- 優先度ハック
＊＊＊＊＊
アーキテクチャの割り切りが、開発・運用を加速する
- 部分部分の見栄えはわるくても、疎結合でいつでもだれでもメンテ可能
＊＊＊＊＊
- 開発・運用の前提がアーキテクチャをシンプルにする
＊＊＊＊＊
- ビジネスへのインパクト
- 社内システムほど試しやすい部分はない、顧客は自分
＊＊＊＊＊
まとめ
- To make it simple, makes our own environments better than before.
- Let's do with your own systems!
＊＊＊＊＊
参考：
- Developers Summit 2014で「社内システムの構造と設計、実装のはなし」という話をした - たごもりすメモ
- 2014/02/13 デブサミ2014【13-B-3】社内システムの構造と設計、実装のはなし #devsumiB - Togetterまとめ
- デブサミ2014「社内システムの構造と設計、実装のはなし」講演メモ #devsumi - 元RX-7乗りの適当な日々
では、前編（わたしが #devsumiB で参加してきたセッションのメモ）は以上です。
次に後編（わたしが #devsumiE で参加してきたセッションのメモ）をこのあとで公開します。
では、とりあえず今は、こんなところで。
