プログラマ 福重 伸太朗 〜基本へ帰ろう〜 このページをアンテナに追加 RSSフィード

2013-03-16

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

発表者について

バズワード化した「DevOps」の言葉の整理

DevOpsとは?

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

幸せになるために

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

DevOps 実践編

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

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

発表者について
会社、サービス
サービスを運用する方法
  • AWS何使ってる?
    • EC2, S3, ELB, CloudFront, Route53, RDS
    • We love RDBMSMySQL, PostgreSQL
    • データストアは Dev/Ops 両方を左右する。
    • AWS依存の設計にするかどうかはよく検討
    • クラウドだから NoSQL, その前に(Twitterも最初はRDBS、なぜ他のデータストアを使うのかはしっかりと考えること)
  • アクション・ファースト
    • 価値提供最重要(安定性も価値)
    • 不確実な未来に対してコミットしすぎない
    • インフラは後からどうにかする(出来る)
  • オートメーション
    • fabric(fabfile.org)
      • 学習コスト低い。移行楽。
    • cuisine(fabricと合わせて使うと良い)https://github.com/sebastien/cuisine
    • シンプル!シンプル!シンプル!
    • botoと組み合わせて使うことで多様な操作が可能
    • cuisine で chef-like な環境構築も
    • Staging & Deployも自動化
    • 自分たちで使ってみないと、わからないよね。という信条。  
    • 自動化そのものを目的にしない
    • 誰でも同じ作業が出来るように
  • モニタリング
    • 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
    • 価値を届けることが目的であって、開発者とかインフラ屋とか関係ない。
    • サービスを運用し始めてから、次に取る舵を選ぶことが出来る柔軟さ。

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

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

toCサービスの要件
  • 規模が予測/コントロール不可能
    • ユーザ数
    • データ量
    • SNS上で突然の(炎上)バズ効果
    • Yahoo!
  • 動いていて当たり前
  • データをなくせない
PDCAをぶんまわす
  • 予測不可能なので、PDCAを短期間のサイクルで回し続ける。
AWSで解決
  • 規模が予測/コントロール不可能
    • => 規模に応じて柔軟に増減できる。また様々なサービスを組み合わせられる。
  • 動いていて当たり前
    • => Multi-AZ、Regions, oute53, S3などなどを柔軟に組み合わせて
  • データをなくせない
    • => S3, RDSなどを組み合わせて
カジュアルにセキュアにAWSを使うために

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

典型的なチーム体制
3つの指針
ACLサーバで制限
WEB用AMIの制限
操作ログの取得
  • sshの操作ログはACLサーバ上でscriptコマンドで全取得
  • 操作ログを含むシステムログはS3→グレイシャーで1年保存
必ず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アカウントくらいカジュアルに稼働中。

クラウドな働き方

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

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

おまけ

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

f:id:japanrock_pg:20130316235705j:image

f:id:japanrock_pg:20130316235752j:image

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/japanrock_pg/20130316/1363446621
リンク元