MY Scribbling...

AWS Community Hero Masanori YAMAGUCHI の 雑なメモ

July Tech Festa 2015に行ってきた

JTF 2015 参加レポート

July Tech Festa 2015(http://2015.techfesta.jp/)に行ってきたので、参加したセッションのレポートを投稿します。

ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから

堀内 康弘(@horiuchi)さんの基調講演

クラウドエンジニアとしての心構え

1. 変化を楽しむ柔軟性

AWSを参考にして技術革新を考えて見る

最初はサーバインフラだけだったが、イノベーションを起こし続けた結果、AWSのサービス数は45へ 一般的に多く使われるものは、共通要素をサービス化している

API Gateway -> Lambda -> Redshift API       ロジック 問い合わせデータ保管

2. 楽しいと思ったものにのめりこもう

楽しいと思ったものに集中して、自分の特有スキルをみにつける 自分の代名詞となるような技術を身につけ、周知できれば更に活動範囲を広げられる

3. 技術は手段であると心得る

あくまでも技術は課題への解決手段であること 手段が目的になってはいけない

よくスタートアップが陥りがちなミス マイクロサービスが流行っているから、うちもマイクロサービスにしよう 結果、管理が難しくて破綻したり、効率が悪くなる

課題が発生した際に、それを解決する際に最も良いと思われるアプローチがマイクロサービス(疎結合化)であれば実行すべき

4. いけてるアニキや仲間をみつけよう

出会いのきっかけの多くはコミュニティ イベント登壇 大学や会社で出会う

ブログやGithubなど、自分の活動内容を公開することが大事 誰かの目に止まる可能性もあるし、知ってもらうことでモチベーション向上や人のつながりを生むきっかけになる

まとめ

変化を楽しむ柔軟性を持とう - 毎日が変化の連続 楽しいと思ったものにのめりこもう - 技術の決定権あり 技術は手段であると心得よう - ビジネス課題の解決を考えざるを得ない いけてるアニキや仲間を見つけよう - CTOのつながり、登壇機会

感想

いつもニコニコしてるから話しかけやすいと言われる、これからも笑顔で生きていけると良いと考えているという言葉が最後に印象的だった。

マイクロサービスでImmutable Infrastructure

しょっさん(@sho7650)さんのセッション

Immutableな話かと思いきやSOAの話だった 所属企業はスポンサーになってしまったため、抽象的な話しかできなくなってしまったらしい

Blue Green Deploymentの課題 ステートレスなサーバとステートフルなサーバの扱い、特にステートフルなサーバ 複雑に結合したアプリケーション、インフラではそもそもハードルが多すぎる

Compotentization 役割分担とインタフェースの明確化 活性保守のしくみ作り メモリのように規格(インタフェース)があって差せば使えるようなモジュールが例 容量を増やしたければ大きいメモリを差し替えればいい

所感 SOAかー、と納得したものの、やっぱりタイトル釣りっぽい感じがw 途中で退席してしまったのでレポート半端ですみません

Modern DevOps with Mackerel

はてな 田中さん(@stanaka)さんのセッション

DevOpsとは

  • Communication, Collaboration アプリケーションエンジニアとインフラエンジニアの協調作業 同じ目標(ビジネスの成長)を向いていること

  • Intagration, Automation, and Measurement

    • 脱職人技・脱属人性
    • 効率向上
    • 再現を容易にする

Modern DevOpsとは

  • 高速なテスト・デプロイ
  • インフラの自動化と効率化

    • 構築(新規・変更)をいかにうまくやるか
    • 観測・監視(パフォーマンス・容量・正常性)を見るべきポイントをいかに見れているか
  • インフラ構築の考え方

    • Immutable Infrastructure
      • できるだけサーバに状態を持たせない(持たせるべきものは持たせる)
      • サーバの作り直し(再現性)を容易にする為
      • The Twelve-Factor App(heroku)のような作り方
    • Infrastructure as Code
      • インフラの設定をコードで管理
      • github上にコード集約
      • Pullreqベースで更新
        • プロビジョニング -> Ansible/Chef/Puppet
        • CI -> Serverspec
        • デプロイ -> Capistranoなど(Fabricとか)
      • デプロイの高速化
        • CIの活用 -> jenkins/CI環境でイメージを自動作成など
      • ChatOps
        • チャットツールを中心としたオペレーション(Slack/Typetalkとか)
  • 例:ステージング環境への自動デプロイ
    • git pushトリガーでproxy設定まで自動化
    • 自動停止時にはゴミを残さない工夫(しばらくアクセスがなかったら自動停止など)
    • botで自動デプロイの通知などをslackに残している

githubかSlackがサービスダウンすると仕事が止まってしまうという外部サービス依存のオペレーションが課題としてある

  • インフラの観測・監視
    • 各種指標を可視化
      • 問題の発生を把握
    • インフラ状態の一元管理
      • サーバリスト
        • サービス・ロールとの対応が重要
        • それぞれの負荷状態と監視状況が可視化できること

インフラの状態を管理/保持する為のMackerel

  • Mackerelとは
    • はてなが提供するエージェント型のメトリクス監視サービス
    • エージェントを導入するとサービス側にメトリクスデータや監視状態などを自動的に送信
    • サービスとロールで分けて監視/管理できるように最適化されたUI
    • 標準で取得できるメトリクス情報以外にCustomメトリクスでproxy情報なども取得可能
    • アラート通知+グラフ情報もSlack, Typetalkに流すことができる
  • メトリクスの送信方法
    • mackerel-agent
    • fluentd
    • cron など
  • 提供API
  • tmux-cssh + mkrコマンド(mackerel apiを叩くコマンドツール)でまとめてsshもできる
    • 同時オペレーションを行う場合とか便利
    • サーバリストの情報をmackerelからとってくるのでロール、サービスごとのサーバ台数やホスト名などを都度調べる必要がない
  • Capistrano連携
    • Ruby Library mackerel/clientというgemがある
    • サーバリストなどと連携できる
  • Ansible
    • Dynamic Inventoryと連携
    • ホスト一覧をJSONで返却するスクリプトがある
    • 適用手順例
      • 起動時にベース設定を入れる
      • Mackerelのサービス・ロールを設定
      • Ansible Dynamic Inventoryでサービス・ロールに紐づくホストをMackerelより引っ張ってくる
  • Autoscaling
    • サーバ増減の様子をグラフで可視化できる
  • 監視ルールもコードで管理
    • 監視ルールAPIが近日リリース予定
    • 監視ルールの反映を github -> Mackerel と連携させることができる!

まとめ

開発ツールクラウドgithub Travis Ci, Circle CI

実行環境もクラウドAWS , GCE

運用ツールクラウドに より効率化 Infrastructure as Codeの推進 インフラの一元管理DBとしてのMackerel

感想

API Meetup Osaka登壇ありがとうございました!これからもMackerelユーザ(無料版ですみません)として使わせてもらいます。目指せプロダクションでの利用!Ansible Dynamic Inventoryとの連携は便利だと思う

失敗例を成功に変える、AWSアンチパターンの数々

Amazon Web Servicesの荒木さん(@ar1)のセッション

うまく組み合わせると効果的なAWSの各種サービスだが、、、

  • サービスが多くてよく分からない、組み合わせが分からない
  • そもそも使い方がわからない

そんな声に応えるためのAWSクラウドデザインパターン

  • 例えば ブログサイトを考える
    • MovableTypeをEC2にインストールする
    • Route53でDNS管理
      • まずはスモールスタートで
  • ブログを開始していくうちに必要な機能が増えてくる
    • 動画、画像など過去の画像集を公開
    • サイズが大きくダウンロード負荷の高いコンテンツを配信する
    • 普通に考えると新しいサーバを立てて機能を追加するが・・・
      • AWS では Web Storageパターンを使うことでサーバを増やさずに機能を追加できるよ
  • ブログ人気が上がりアクセス負荷があがってきた
    • サーバを増やせば対応できるけど、費用がかかる
      • Direct Hostingパターン
        • MovableTypeで作ったデータはすべてS3へ、サイト訪問者はS3のデータをアクセスする
        • データを作った後は、EC2は停止していても良い
      • S3をメインサイトにする
        • Route53で今までWeb URLをS3のIPに誘導することでサービス無停止で対応
  • 海外展開を考える
  • キャッシュの効果的な利用でサイトの効率化を図る

クラウドデザインアンチパターンについて

1回決めたシステムはなかなか変えられない 成功パターンは「秘伝のたれ」化されて、変えてはいけないものとされるケースもある

失敗に陥るパターンを早期に見つけ、対応策としての提案していくことが目的 リファクタリングするための方法としてのパターンもある

ここで紹介するアンチパターンは全部で13

EC2にまつわる7つのパターン

  • EC2一神教アンチパターン

    • 原因:AWSの知識が古いままでとまっている、サーバ調達、その上で作る方法に慣れ親しんでいる。アプリケーションエンジニアとのコミュニケーションが脆弱なインフラエンジニアが陥りやすいパターン。
    • 症状:目的(Web、Proxyなどなど)ごとにEC2を用意するためにインスタンス数が増えて、可用性・バックアップの担保に手間がかかる
    • 解決方法:SQS、Route53、RDS、S3、ELB、などEC2以外のサービスを活用する
  • ノースナップショットアンチパターン

    • 原因:EBSのスナップショットを知らない、高価だと思っている (1度目のスナップショットはディスク全体だが、次回以降は増分の課金対象になる)
    • 症状;別AZからEBSが使えないことで気づく、操作ミスでファイルを消してから取り返しのつかないことに気づく
    • 解決方法:何か新しいことをする場合はスナップショットをとる、定期的に不要なスナップショットは消す
  • AMIなしアンチパターン

    • 原因:AMI作りが難しいと思っている、オンプレでの作業慣れていてインストール手順に固執する
    • 症状:インスタンスをイチから用意するため、サービスイン時に時間がかかる。サービス拡張時も手順がないと対処できない。作業品質のバラつきもリスクとして残る。
    • 解決方法:AMI作成をまずやってみる
  • AMI至上主義パターン(AMI作成をバックアップとして考えちゃうパターン)

    • 原因:AMI作成をバックアップだと思っている
    • 症状:動作中にAMIは作れない、S3バックのインスタンスはAMIが作れないと思ってしまう
    • 解決方法:EBSスナップショットを使う、適材適所のバックアップを使うこと
  • インスタンス振動アンチパターン(AutoScalingの設定が敏感すぎて無駄に課金が増える)

    • 原因:AutoScalingの設定が敏感すぎる(CPUの使用率で30%でスケールアウト、20%でスケールインなど、リスクを考えすぎて条件を敏感に設定してしまう)、CloudWatchの条件ソースが不適切
    • 症状:増減にともなう課金増加(MackerelなどのAutoScale監視をしていれば早期に気づける可能性は高い)
    • 解決方法:起動条件の4倍程度に緩和させる(CPU80%でスケールアウトなら、20%でスケールインなど)、1時間ごとの課金なので55分でインスタンスを停止させるスクリプトを仕込んでおくなど
  • 単機能AZアンチパターン

    • 原因:可用性を担保する為に、サブネットごとにDB用,アプリ用などと分けてしまうそれぞれを複数設置し忘れる
    • 症状:特定の機能が単一のAZにしかないので、そのAZが障害を起こすとシステム全停止になってしまう
    • 解決方法:ELB,RDSなど複数AZを使うサービスの導入、機能別にサブネットを分けたら、そのサブネットは同じものを別AZにも作成する。最初に開発するときはシングルAZで開発を進める。
  • とりあえずELBアンチパターン

    • 原因:冗長化の為には必ずロードバランサーを行いといけないと古い知識のまま勘違いしている
    • 症状:サーバからのプッシュができない、出来たとしても手間がかかる仕組みが必要
    • 解決方法:モダンブラウザ x DNSラウンドロビン

EC2以外のアンチパターン

  • CloudFrontを使わないアンチパターン

    • 原因:配信先が日本だけなのでいらないと考える、キャッシュ設定を嫌う
    • 症状:HTTPアクセスピーク時に待機気が律速に、CPUやディスクに余裕があるのに捌けない
    • 解決方法:CloudFrontのレスポンスを体験してみる、オリジンサーバのキャッシュ設定を適切にする
  • ベンチマークソフトウェアアンチパターン

    • 原因:システム実態と違うベンチマークツールを使ってしまう、本番と特定時の規模の差がある
    • 症状;パフォーマンス不足、コスト過多
    • 解決法:本番システムと同じシステムを一時的に確保できるのでそれを使って適切なベンチツールで測定する

ウェブアプリケーション以外のアンチパターン

  • ノールック明細アンチパターン

    • 原因:月末の料金請求しかないと思ってる
    • 症状:支払い周期のズレ、クレジットカード与信枠使い切り
    • 解決方法:明細をちゃんとみる、AWSには料金を確認する機能がたくさんある、x分からない事はカスタムサービスへ
  • インフラ塩漬けアンチパターン

    • 原因:構築した当初のままインフラの見直しが入らない
    • 症状;実際の利用に比べてキャパシティの過不足を放置している
    • 解決方法;1年に1度は見直す事を推奨
  • 机上の空論アンチパターン

    • 原因:サーバ発注、システムデプロイ、納品のウォータオールモデルから抜け出せない
    • 症状:動作確認をしない、事前のキャパシティプランニングに時間をかけすぎる
    • 解決方法:まずは小さく試してみること

まとめ

クラウドデザインパターンを活用しよう 失敗経験の共有、失敗は打開策までもっていくことが重要 失敗経験は共有することでアンチパターンとなり、とても有益な情報となる

感想

失敗経験の共有は成功経験の共有よりも有益なるのは大きく同意。自分も失敗経験はどんどん共有していきたい、失敗しないことが一番だけどね

セキュリティ的に「硬い」インフラを作ろう ― MINI Hardening Project

AWSサポートエンジニアの坪さん(@TSB_KZK)

Hardening Projectとは

  • WASForumが取り組むセキュリティイベント
  • 守る技術を持つエンジニアと発掘・顕彰するコンペティション
  • これまでに6回開催されている

  • 競技は8時間で無防備なサーバ群をひたすら守りつつ、ECサイトの売り上げを競う

    • 1チーム6名
    • 20台前後の仮想サーバ(Linux/Windows混在)
    • リアルタイムに状況が変化する
      • 負荷によるサービス停止、運営からの攻撃など

なぜMINI Hardening Projectが生まれたのか

  • 場所の問題、本家は沖縄で開催されている
  • 土日開催で二日間に渡って参加が必要
  • セキュリテイに関連するイベントで情報が少なく難易度が高い
  • 過去問など再現できる類のものが無い

    • 会社でノウハウ共有などが難しい、再現するにも攻撃者を用意するのは難しい
  • 東京などの需要の多い場所で土日いずれかの3時間で開催されている

  • 競技、フィードバックもあるが、攻撃を体験してもらうことが主目的

競技環境

  • AWSを利用
  • VPCでプライベートネットワーク
  • 各チームに3台のインスタンスを提供
  • 脆弱なバージョンのソフトウェア、ミドルウェアを用意
  • ありがちな脆弱性シナリオを用意
    • デフォルト設定で起動
    • アクセス制限なし
    • フロントのiptablesがから
    • パスワードが脆弱

評価

  • 環境と報告書の両面から確認
  • スクリプトで環境変化をチェック
  • 報告書との突合
  • クローラが計測したSLAスコアと合わせて総合点を算出
  • 全チーム分を評価、フィードバック

攻撃に関して

  • 攻撃に関しては概要の説明があったが割愛
  • 攻撃に気づくことは結構難しい
    • DDoSによるSLA低下
      • 評価用クローラの表示をみてダウンに気づくケースもある
      • ターミナルがなんとなく重いとか
    • yum.dのreposにgpgcheckが外れていたりしてバックドアが仕掛けられたパッケージにバージョンアップされるとか
    • metasploitを使うこともあるらしい

クローラに関して

  • サービス環境のSLAを評価している

練習したい人向け

感想

久しぶりにセキュリティに関わるセッションを聞いたので、忘れかけていたことや、知らなかったことを聞けてとても良かった。影響を受けてJTF枠でMINI Hardening Projectに申し込みました。(抽選通りました!)

セキュリティインシデントを経験することは多くないと思うけど、一度体験してみると本当にセキュリティインシデントに遭遇した時や、インシデントに気づく勘も鍛えられると思うのでみなさんも是非!

HashiCorpとAtlasのインフラ管理 ― 運用に自動化を求めるのは間違っているだろうか(仮)

クリエーションラインの前佛(@zembutsu)さんのセッション

運用の変化

  • 働いたら負け(刺身タンポポ、写経など手動のモチベ上がらないルーチンワークから自動化へという意)
  • 〜2000年まではMRTGへの死活管理が主体
  • 〜2009年はMunin, Zabbixによる時系列リソース監視へ、アクセス集中時間帯へのサービス品質維持の対応
  • 現在は、クラウドによる時系列サービスへ

  • さらにコンテナ化が進むと、これまでやり方でOpsは生き残れるのだろうか

  • TMTOWTDI

  • 自分が使える運用ツールの最強デッキを用意することも1つの方法ではないか

物理からコンテナへ

  • すべてを迅速に、一貫性を持たせて再現性を容易に
  • Dockerがなぜ注目/浸透してきているのか
    • 速さ
    • ポータビリティ
    • 再現性
  • docker machine
    • boot2dockerの後継
    • boot2dockeと違いローカル以外にクラウド環境なども利用可能
  • Docker Compose
    • 旧名:fig
    • 複数のDockerコンテナを1つの環境として管理する
  • Dockerと仮想化システム、構成管理ツールクラウド環境を比較するのは比較軸が異なるから向いていない
  • docker.jpドメインの所有者は前佛さん、Dockerの情報を公開するサイトとして準備中  

    Hashicorpについて

  • 技術ではなくどのように実現するのか(from Tao of Hashicorp) 手段が目的にならないようにっていうことと共通してる
  • Vagrant, Packer, Serf, Consul, Terraform, Atlasなどツールの概要紹介

まとめ(意訳)

  • 自分の手を動かす、自分で触る、自分で使った経験を大事にする
  • ツールありきで考えない、最適なツールを必要な場面で使うこと
  • 手動のルーチンワークを排除していく結果、速さ、効率性、自動化を実現できる
  • そうした経験を経て蓄積したノウハウが自分の最強デッキになり今後起こりうる変化にも対応できるOpsになれる

感想

物理サーバ、仮想化、コンテナというサーバの変遷から運用を取り巻く環境の変化。DockerおよびDockerを取り巻くツール群、Hashicorpのツール説明だけではなく、なぜそれらのツールが必要となってきているのか、といった背景まで触れたボリューム満点の内容だった。ただ、ボリュームが多すぎて全体をザーッと駆け足で進む形だったのでもう少し聞きたかった。前佛さんのスライドは相変わらずネタであふれているw

全体を通しての感想

昨年初めて参加して今回は2回目でした。去年は構成管理ツールやHashicorp、OpenStack、CloudStackの概要を話すセッションが多かった気がするけど、今年は一歩踏み込んだ内容多く日々の活動に刺激になる情報をたくさん得られたので参加して本当に良かったです。

あと、セッションもさることながら、飲み物や軽食、さらにはお弁当も配布されたり、実行委員の方の事前準備に掛かる労力はとても大変だと思います。(API Meetupというコミュニティを運営していますが、3時間のmeetup + 懇親会を企画するだけでも事前準備が結構大変なんです)

来年はスピーカーとして協力出来ればと思います。実行委員会のみなさま、スタッフのみなさま、ありがとうございました!