JAWS DAYS 2013に参加してきた
JAWS DAYS 2013に参加してきました。3/16(土)のみ参加しました。3/15(金)は行けませんでした。。
JAWS DAYS 2013で、目立ったキーワードが「DevOps」でした。ほとんどのセッションで1回は単語が登場したのではないでしょうか。DevOpsという概念は2010年(2009年?)くらいからあったようです。しかし、日本で多くの人に認知されたのは今年ではないでしょうかね。
私のDevOpsの認識は、経営で言うところの「クロスファンクショナル」に近い概念とだ思っています。クラウド、GitHub等の登場によってDevとOpsの共通言語ができ、お互いをより深いところまで理解し合い、高めあえるようになったという印象です。Devはアプリのコードを書くし、Opsはインフラのコードを書く。場合によってはDevとOpsが同じ言語で書けるでしょう。DevがOpsのコードを見てやろうとしていることに対してフィードバックを行う、逆もしかり。DevもOpsも価値の高いサービスを提供するという目標は同じなわけですから、フィードバックしあえることで、価値の高いサービスを提供しやすくなると感じます。
下記はセッションのメモです。
インフラエンジニアが開発者と実践しているDevOpsな現場のお話
http://jaws-ug.jp/jawsdays2013/speaker.html#OPS-01
発表者について
- @ume3
- ブログ:インフラエンジニアに成る
- Ops:4年目
- サーバの構築・保守・運用を担当
- しゃべるインフラの人です
バズワード化した「DevOps」の言葉の整理
DevOpsとは?
開発者と運用者の壁をなくすこと
DevOps 実践編
- Opsとは
- Web Applicationを構築・運用・保守の面から支える人
- 今までのOps
- データセンターに行って、サーバを構築。帰ったらサーバの保守手順書を作成して、夜間メンテの運用準備もしなきゃな。日曜日は監視・・。
- 今のOps
- 運用で必要な力
- 手動作業の自動化
- コードがかけてツールも使える。
- パフォーマンスチューニング
- 性能監視
- ハードウェアやミドルウェアのチューニング
- 守り(保守)から攻め(運用)へ
- 手動作業の自動化
- Opsは自然にDevツールの力を求める
- Devは、ハードウェアをAPIとして見ることが出来る。(インフラのコード化)
- Opsは、運用に時間を書けることが出来る(ハードウェア保守からの脱却)
- これがやりたい!を言いあえる関係に一歩前進。
- DevとOpsで自然とコミュニケーションが生まれる。
- Gitでコードの世代管理
- GitHubのIssueやWikiを活用
- DevとOpsのコミュニケーションにかかせない。
- pull Requestする文化(プルリク分化)
- GitHubでPuppetコードを管理する。
- OpsがPushかつPull Reqなことも。
- Puppet
- 構成管理ツールで手順書のコード化
- 独自のレシピでミドルウェアの「ふるまい」や設定ファイルを役割ごとに管理できる。
- サーバ構築の自動化
- 構成を自動化する前に
- Opsだけで構成管理するのは難しい。
- Devと一緒に話し合って設計した上で、自動化について考える必要がある。
- IRC、Botコミュニケーション
- Webistrano(自動デプロイツール、CapistranoをWebアプリでラッパしたもの(Ruby製)。GUI操作でデプロイ可能)
- 開発環境の構築はDevがやる。
- DevでできるインフラのことはOpsがやらず、Devがやる。
- タスクの可視化。
- Fluentdでログ基盤
- ログの管理は曖昧
- DevOpsっぷりがためされる。
- Fluentdでログ採取
- 採取閲覧の仕組みをOpsが用意
- Devはログの確認の仕組みを用意することも
- ログの管理は曖昧
- DevOpsが当たり前の世界へ
AWSを活用して小さなチームで世界で使われるサービスを運用する方法
http://jaws-ug.jp/jawsdays2013/speaker.html#OPS-04
会社、サービス
- ヌーラボ nulab http://www.nulab.co.jp/
- Backlog
- 13万ユーザ
- WebDavによるファイル共有
- GitやSubversionのリポジトリホスティング
- Cacco https://cacoo.com/lang/ja/
- 副数のユーザで同時に編集できるリアルタイムコラボレーション
- 開発プロセスについては、Web+DB vol 72に書いてある。
- Cacco for Google+ Hangouts
- Backlog, Caccoというユーザの急増したサービスを2人のエンジニアでやっていけている。AWSのおかげ。
- Developer's role
サービスを運用する方法
- AWS何使ってる?
- アクション・ファースト
- 価値提供最重要(安定性も価値)
- 不確実な未来に対してコミットしすぎない
- インフラは後からどうにかする(出来る)
- オートメーション
- fabric(fabfile.org)
- 学習コスト低い。移行楽。
- cuisine(fabricと合わせて使うと良い)https://github.com/sebastien/cuisine
- シンプル!シンプル!シンプル!
- botoと組み合わせて使うことで多様な操作が可能
- cuisine で chef-like な環境構築も
- Staging & Deployも自動化
- git更新
- Jenkinsで通ったら、fabricによる環境初期化デプロイ。
- Seleniumの実行
- fabricによるデプロイ(ベータ環境)
- git更新
- 自分たちで使ってみないと、わからないよね。という信条。
- 自動化そのものを目的にしない
- 誰でも同じ作業が出来るように
- fabric(fabfile.org)
- モニタリング
- 障害の想定
- Multiple AZ
- ネットワーク遅延が問題になったことはない
- AZ間での通信障害に対する監視はしておく
- まだゾーン障害を経験していない..
- Multi tenancy
- ビジネス向き or 一個人向き
- 影響範囲が限定される安心感は(かなり)大きい
- 外部サービスとの連携に工夫が要る場合も
- Instanse Role
- 各サービスに役割を分けましょう。
- If service failure happen
- サイトは別のリージョン or 別サービスで管理(障害の時に、ユーザが障害情報にリーチするために)
- Multiple AZ
- まとめ
- Dev = Ops for a small team
- 価値を届けることが目的であって、開発者とかインフラ屋とか関係ない。
- サービスを運用し始めてから、次に取る舵を選ぶことが出来る柔軟さ。
ランキング1位の人気スマホアプリをカジュアルにセキュアに運用するノウハウ、教えます
http://jaws-ug.jp/jawsdays2013/speaker.html#OPS-05
toCサービスの要件
AWSで解決
- 規模が予測/コントロール不可能
- => 規模に応じて柔軟に増減できる。また様々なサービスを組み合わせられる。
- 動いていて当たり前
- => Multi-AZ、Regions, oute53, S3などなどを柔軟に組み合わせて
- データをなくせない
- => S3, RDSなどを組み合わせて
カジュアルにセキュアにAWSを使うために
アプリエンジニアでも安全に = カジュアルにセキュアに
典型的なチーム体制
- 主に企画 1人
- 主にアプリ開発 2人
- no infra specialist(インフラエンジニアなし)
3つの指針
必ずELB
- 攻撃者に攻撃の手がかりを与えない
- 手がかり:使用ミドルウェアやバージョン情報
- ELBを通すと、手がかりを隠蔽される
- もちろん、必要なポートだけ開ける
Auto Scaling
- サービスが常に動いている状態をカジュアルに構築するため
- 1台の場合でも設定 = サーバがコケた時もサービス継続
- 突発的なバズ効果にも対応
事例を紹介
- Ambrotype
- newsHUB
- ニュースを素早く把握
- アプリはJSONをとるために、直接S3を観に行っている。
- Cameran
- ユーザはほぼ女性。カメラアプリは女性向けにするとよい。
現在60アカウントくらいカジュアルに稼働中。
クラウドな働き方
セッション「クラウドの働き方」については、パソコンの電源がなくなったので、思い出しながらメモしています。
- クラウド登場以前では、育児や介護などで場所や時間の制約を受けることになった場合、システム開発やインフラの仕事を続けるのは困難である場合が多々あったのではと思います。しかし、クラウドの登場で遠隔地にいながら、システム開発を進めたり、インフラの構築を行えたりすることが可能になりました。
- クラウドの登場で、働き方の選択肢が増え、育児や介護の影響を受けても今の仕事を続けることが可能になる場合があり、救われる人も多々いるだろうなと思いました。会社も働いている人も家族もお客様も世間も皆笑顔が増えそうですね。とてもステキなことですね。
- 介護の課題をクラウドで乗り越える
- リモート勤務で大切なことが「信頼」だと言っていました。信頼できないのであれば、少し試してみればいい、駄目ならやめたらいいと言っていました。
- リモート勤務は働き方はもちろん、家族のあり方まで変えられるかもしれないと言っていました。東京で子供が育つのか、北海道で子供が育つのか、体験することが全然違うと思います。家族と過ごす時間が増え、よりハッピーになるかもしれない。リモート勤務によってハッピーになれる人、会社があるかもしれませんね。
- 地方に行った時に、コミュニティがあると安心すると言っていました。地域コミュニティは地方ユーザに安心感を与えているのですね。