プログラマ 福重 伸太朗 〜基本へ帰ろう〜

JAWS DAYS 2013に参加してきた

AWS

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」の言葉の整理

• Dev [Development]
  • 開発者 / デベロッパ
• Ops [Operations]
  • 運用者 / インフラエンジニア
• Dev文化とOps文化の共有

DevOpsとは？

開発者と運用者の壁をなくすこと

幸せになるために

• DevからOpsへのお願い作業を減らす
• GitHubでPull Requestする関係
• 積極的なクラウドの活用
• Devが開発環境を構築・管理

DevOps 実践編

• Opsとは
  • Web Applicationを構築・運用・保守の面から支える人
• 今までのOps
  • データセンターに行って、サーバを構築。帰ったらサーバの保守手順書を作成して、夜間メンテの運用準備もしなきゃな。日曜日は監視・・。
• 今のOps
  • クラウドのAPIでサーバ構築の自動化。手順書もコード化して柔軟に。保守時は短時間で復旧。
  • 構築 : 20%、運用 : 20%、保守 : 60%　→　構築 : 20%、運用 : 60%、保守 : 20%
  • リリース後の運用に力を入れる。
• 運用で必要な力
  • 手動作業の自動化
    • コードがかけてツールも使える。
  • パフォーマンスチューニング
    • 性能監視
    • ハードウェアやミドルウェアのチューニング
  • 守り（保守）から攻め（運用）へ
• Opsは自然にDevツールの力を求める
  • クラウド
    • AWS
  • 構成管理
    • Puppet / chef
  • リビジョン管理
    • Git
  • 情報共有
    • IRC / Github
  • デプロイメント
    • Jenkins / webistrano
  • プロジェクト管理
    • Agile / 付箋紙
• Devは、ハードウェアをAPIとして見ることが出来る。（インフラのコード化）
• Opsは、運用に時間を書けることが出来る（ハードウェア保守からの脱却）
• これがやりたい！を言いあえる関係に一歩前進。
• DevとOpsで自然とコミュニケーションが生まれる。
  • Gitでコードの世代管理
  • GitHubのIssueやWikiを活用
  • DevとOpsのコミュニケーションにかかせない。
  • pull Requestする文化（プルリク分化）
    • 例：Ops管理の設定ファイルを変更したい。DevがOpsへPull Requestして確認後、Merge
  • GitHubでPuppetコードを管理する。
  • OpsがPushかつPull Reqなことも。
  • Puppet
  • 構成管理ツールで手順書のコード化
    • 独自のレシピでミドルウェアの「ふるまい」や設定ファイルを役割ごとに管理できる。
    • サーバ構築の自動化
  • 構成を自動化する前に
    • Opsだけで構成管理するのは難しい。
    • Devと一緒に話し合って設計した上で、自動化について考える必要がある。
  • IRC、Botコミュニケーション
  • Webistrano（自動デプロイツール、CapistranoをWebアプリでラッパしたもの(Ruby製）。GUI操作でデプロイ可能）
• 開発環境の構築はDevがやる。
  • Opsが構成管理したVM（仮想マシン）を使う
  • Devがある程度管理する
• DevでできるインフラのことはOpsがやらず、Devがやる。
• タスクの可視化。
• Fluentdでログ基盤
  • ログの管理は曖昧
    • DevOpsっぷりがためされる。
  • Fluentdでログ採取
    • 採取閲覧の仕組みをOpsが用意
    • Devはログの確認の仕組みを用意することも
• DevOpsが当たり前の世界へ
  • DevはOpsといっしょにOpsをするしOpsはDevといっしょにDevをする。

AWSを活用して小さなチームで世界で使われるサービスを運用する方法

http://jaws-ug.jp/jawsdays2013/speaker.html#OPS-04

発表者について

• tksmd
• d.hatena.ne.jp/tksmd
• JAWS UG 京都支部長

会社、サービス

• ヌーラボ 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というユーザの急増したサービスを２人のエンジニアでやっていけている。AWSのおかげ。
• Developer's role
  • Dev、Ops、Support、Sales、Marketing　> MSDOS

サービスを運用する方法

• AWS何使ってる？
  • EC2, S3, ELB, CloudFront, Route53, RDS
  • We love RDBMS（MySQL, PostgreSQL）
  • データストアは Dev/Ops 両方を左右する。
  • AWS依存の設計にするかどうかはよく検討
  • クラウドだから NoSQL, その前に（Twitterも最初はRDBS、なぜ他のデータストアを使うのかはしっかりと考えること）
• アクション・ファースト
  • 価値提供最重要（安定性も価値）
  • 不確実な未来に対してコミットしすぎない
  • インフラは後からどうにかする（出来る）
• オートメーション
  • fabric（fabfile.org）
    • 学習コスト低い。移行楽。
  • cuisine（fabricと合わせて使うと良い）https://github.com/sebastien/cuisine
  • シンプル！シンプル！シンプル！
  • botoと組み合わせて使うことで多様な操作が可能
  • cuisine で chef-like な環境構築も
  • Staging & Deployも自動化
    • git更新
      • Jenkinsで通ったら、fabricによる環境初期化デプロイ。
      • Seleniumの実行
      • fabricによるデプロイ（ベータ環境）
  • 自分たちで使ってみないと、わからないよね。という信条。　　
  • 自動化そのものを目的にしない
  • 誰でも同じ作業が出来るように
• モニタリング
  • uptimer.at（外からの監視）
  • Nagios（内部からの監視）
  • mon / munin
  • Cloudwatch（AWS）
  • fluentd
  • Cloudwatch BK?!
  • 異常があったらツールに呼んでもらう
  • 障害を再発しないために検知項目を増やす
  • 監視のクオリティを保つ
• 障害の想定
  • Multiple AZ
    • ネットワーク遅延が問題になったことはない
    • AZ間での通信障害に対する監視はしておく
    • まだゾーン障害を経験していない..
  • Multi tenancy
    • ビジネス向き or 一個人向き
    • 影響範囲が限定される安心感は（かなり）大きい
    • 外部サービスとの連携に工夫が要る場合も
  • Instanse Role
    • 各サービスに役割を分けましょう。
  • If service failure happen
    • サイトは別のリージョン or 別サービスで管理（障害の時に、ユーザが障害情報にリーチするために）
• まとめ
  • Dev = Ops for a small team
  • 価値を届けることが目的であって、開発者とかインフラ屋とか関係ない。
  • サービスを運用し始めてから、次に取る舵を選ぶことが出来る柔軟さ。

ランキング１位の人気スマホアプリをカジュアルにセキュアに運用するノウハウ、教えます

http://jaws-ug.jp/jawsdays2013/speaker.html#OPS-05

toCサービスの要件

• 規模が予測/コントロール不可能
  • ユーザ数
  • データ量
  • SNS上で突然の（炎上）バズ効果
  • Yahoo!砲
• 動いていて当たり前
  • スマホアプリはサーバの状態が表に出ない
• データをなくせない

PDCAをぶんまわす

• 予測不可能なので、PDCAを短期間のサイクルで回し続ける。
  • iOSアプリの場合、２週間・・

AWSで解決

• 規模が予測/コントロール不可能
  • => 規模に応じて柔軟に増減できる。また様々なサービスを組み合わせられる。
• 動いていて当たり前
  • => Multi-AZ、Regions, oute53, S3などなどを柔軟に組み合わせて
• データをなくせない
  • => S3, RDSなどを組み合わせて

カジュアルにセキュアにAWSを使うために

アプリエンジニアでも安全に = カジュアルにセキュアに

典型的なチーム体制

• 主に企画 1人
• 主にアプリ開発 2人
• no infra specialist（インフラエンジニアなし）

３つの指針

• ACLサーバによるssh制限
  • アプリエンジニアはネットワーク / セキュリティ苦手
  • 社外のアプリエンジニアさん。SSH 0.0.0.0/0
• 必ずELBを使う
• Auto Scaling を使う

ACLサーバで制限

• 自分の接続元IPを簡単にSecurityGroupに登録する画面を設置
  • スマホでカジュアルにSSH

WEB用AMIの制限

• iptablesやhosts.allow/denyでインターネットからのsshを拒否。
  • Security Groupを設定されちゃっても大丈夫。
• sshはACLサーバからのみ

操作ログの取得

• sshの操作ログはACLサーバ上でscriptコマンドで全取得
• 操作ログを含むシステムログはS3→グレイシャーで１年保存

必ずELB

• 攻撃者に攻撃の手がかりを与えない
  • 手がかり：使用ミドルウェアやバージョン情報
• ELBを通すと、手がかりを隠蔽される
• もちろん、必要なポートだけ開ける

Auto Scaling

• サービスが常に動いている状態をカジュアルに構築するため
• 1台の場合でも設定 = サーバがコケた時もサービス継続
• 突発的なバズ効果にも対応

basic architecture

• EC2(ACL) sshの踏み台。操作ログ取得

以上を守れば、あとは自由にやってね。

事例を紹介

• Ambrotype
  • 1827年、人類初の写真。
  • 現在は写真の20%はFacebookに投稿されている。
  • 複数のサイトにアップロードした写真をまとめてくれる。
    • 技術トピック
      • 各SNS / クラウドサービスのAPIを叩きまくる。
      • 対応サービス毎にAPI仕様が全く異なる。
  • 構成
    • （Public）Route53 - ELB、 （AZ1）EC2 EC2（クローラ） RDS、（AZ2）EC2 RDS（スタンバイ）
• newsHUB
  • ニュースを素早く把握
  • アプリはJSONをとるために、直接S3を観に行っている。
• Cameran
  • ユーザはほぼ女性。カメラアプリは女性向けにするとよい。

現在60アカウントくらいカジュアルに稼働中。

クラウドな働き方

セッション「クラウドの働き方」については、パソコンの電源がなくなったので、思い出しながらメモしています。

• クラウド登場以前では、育児や介護などで場所や時間の制約を受けることになった場合、システム開発やインフラの仕事を続けるのは困難である場合が多々あったのではと思います。しかし、クラウドの登場で遠隔地にいながら、システム開発を進めたり、インフラの構築を行えたりすることが可能になりました。
• クラウドの登場で、働き方の選択肢が増え、育児や介護の影響を受けても今の仕事を続けることが可能になる場合があり、救われる人も多々いるだろうなと思いました。会社も働いている人も家族もお客様も世間も皆笑顔が増えそうですね。とてもステキなことですね。
• 介護の課題をクラウドで乗り越える
• リモート勤務で大切なことが「信頼」だと言っていました。信頼できないのであれば、少し試してみればいい、駄目ならやめたらいいと言っていました。
• リモート勤務は働き方はもちろん、家族のあり方まで変えられるかもしれないと言っていました。東京で子供が育つのか、北海道で子供が育つのか、体験することが全然違うと思います。家族と過ごす時間が増え、よりハッピーになるかもしれない。リモート勤務によってハッピーになれる人、会社があるかもしれませんね。
• 地方に行った時に、コミュニティがあると安心すると言っていました。地域コミュニティは地方ユーザに安心感を与えているのですね。

おまけ

ブースやセッション、アンケートの見返りで沢山ステッカーを貰いました。そして、パソコンに貼りました。パソコンにステッカーを無造作に貼るのは妻には非常に不評です（笑）　でもいいんです。それぞれのステッカーには想い出が詰まっていて、それを見ればあのときの風景を思い出すのです。最近は、ステッカーの貼る場所がなくなってきてますが、ステッカーの上に張っちゃえばいいやって思ってます。スペースには限りがあるので仕方ないのです。ステッカーの一部しか見えなくても、それはそれでデザインだと思ってしまえばいいやと思ってます。

• 表

• 裏

Permalink | コメント(0) | トラックバック(0) | 00:10