July Tech Festa 2015に行ってきた
JTF 2015 参加レポート
July Tech Festa 2015(http://2015.techfesta.jp/)に行ってきたので、参加したセッションのレポートを投稿します。
ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから
堀内 康弘(@horiuchi)さんの基調講演
クラウドエンジニアとしての心構え
１. 変化を楽しむ柔軟性
- 日々変化する技術に対して、変化を楽しむ事が重要
- 未来は予測できないけど、変化は起こり続けることは確実
- 要因はイノベーション、イノベーションが変化を起こし続ける
- 今あることをもっと楽にするためにイノベーションは発生する
- イノベーションにより時間ができて、できた時間で更なるイノベーションが起こる
- CVS, Subversion, Git
- ウェブアプリケーションフレームワーク
- クラウドコンピューティング
AWSを参考にして技術革新を考えて見る
最初はサーバインフラだけだったが、イノベーションを起こし続けた結果、AWSのサービス数は45へ 一般的に多く使われるものは、共通要素をサービス化している
API Gateway -> Lambda -> Redshift API ロジック 問い合わせデータ保管
２. 楽しいと思ったものにのめりこもう
楽しいと思ったものに集中して、自分の特有スキルをみにつける 自分の代名詞となるような技術を身につけ、周知できれば更に活動範囲を広げられる
3. 技術は手段であると心得る
あくまでも技術は課題への解決手段であること 手段が目的になってはいけない
よくスタートアップが陥りがちなミス マイクロサービスが流行っているから、うちもマイクロサービスにしよう 結果、管理が難しくて破綻したり、効率が悪くなる
課題が発生した際に、それを解決する際に最も良いと思われるアプローチがマイクロサービス(疎結合化)であれば実行すべき
４. いけてるアニキや仲間をみつけよう
出会いのきっかけの多くはコミュニティ イベント登壇 大学や会社で出会う
ブログや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とか)
- Immutable Infrastructure
- 例：ステージング環境への自動デプロイ
- git pushトリガーでproxy設定まで自動化
- 自動停止時にはゴミを残さない工夫(しばらくアクセスがなかったら自動停止など)
- botで自動デプロイの通知などをslackに残している
githubかSlackがサービスダウンすると仕事が止まってしまうという外部サービス依存のオペレーションが課題としてある
- インフラの観測・監視
- 各種指標を可視化
- 問題の発生を把握
- インフラ状態の一元管理
- サーバリスト
- サービス・ロールとの対応が重要
- それぞれの負荷状態と監視状況が可視化できること
- サーバリスト
- 各種指標を可視化
インフラの状態を管理/保持する為のMackerel
- Mackerelとは
- はてなが提供するエージェント型のメトリクス監視サービス
- エージェントを導入するとサービス側にメトリクスデータや監視状態などを自動的に送信
- サービスとロールで分けて監視/管理できるように最適化されたUI
- 標準で取得できるメトリクス情報以外にCustomメトリクスでproxy情報なども取得可能
- アラート通知+グラフ情報もSlack, Typetalkに流すことができる
- メトリクスの送信方法
- mackerel-agent
- fluentd
- cron など
- 提供API
- ホスト一覧
- ホスト状態の更新
- 時系列情報の取得
- jsonで返ってくるのでjqでパースすると便利
- 詳細はAPIガイドを参照(http://help-ja.mackerel.io/entry/spec/api/v0)
- tmux-cssh + mkrコマンド(mackerel apiを叩くコマンドツール)でまとめてsshもできる
- 同時オペレーションを行う場合とか便利
- サーバリストの情報をmackerelからとってくるのでロール、サービスごとのサーバ台数やホスト名などを都度調べる必要がない
- Capistrano連携
- Ruby Library mackerel/clientというgemがある
- サーバリストなどと連携できる
- Ansible
- Autoscaling
- サーバ増減の様子をグラフで可視化できる
- 監視ルールもコードで管理
まとめ
開発ツールはクラウドへ github Travis Ci, Circle CI
運用ツールもクラウドに より効率化 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に誘導することでサービス無停止で対応
- Direct Hostingパターン
- サーバを増やせば対応できるけど、費用がかかる
- 海外展開を考える
- Amazon CloudFrontでキャッシュ配信することでメインサイトをアクセス過多から守る
- キャッシュの効果的な利用でサイトの効率化を図る
クラウドデザインアンチパターンについて
１回決めたシステムはなかなか変えられない 成功パターンは「秘伝のたれ」化されて、変えてはいけないものとされるケースもある
失敗に陥るパターンを早期に見つけ、対応策としての提案していくことが目的 リファクタリングするための方法としてのパターンもある
ここで紹介するアンチパターンは全部で１３
EC2にまつわる７つのパターン
ノースナップショットアンチパターン
- 原因：EBSのスナップショットを知らない、高価だと思っている (1度目のスナップショットはディスク全体だが、次回以降は増分の課金対象になる)
- 症状；別AZからEBSが使えないことで気づく、操作ミスでファイルを消してから取り返しのつかないことに気づく
- 解決方法：何か新しいことをする場合はスナップショットをとる、定期的に不要なスナップショットは消す
AMIなしアンチパターン
- 原因：AMI作りが難しいと思っている、オンプレでの作業慣れていてインストール手順に固執する
- 症状：インスタンスをイチから用意するため、サービスイン時に時間がかかる。サービス拡張時も手順がないと対処できない。作業品質のバラつきもリスクとして残る。
- 解決方法：AMI作成をまずやってみる
AMI至上主義パターン(AMI作成をバックアップとして考えちゃうパターン)
- 原因：AMI作成をバックアップだと思っている
- 症状：動作中にAMIは作れない、S3バックのインスタンスはAMIが作れないと思ってしまう
- 解決方法：EBSスナップショットを使う、適材適所のバックアップを使うこと
単機能AZアンチパターン
とりあえずELBアンチパターン
EC2以外のアンチパターン
CloudFrontを使わないアンチパターン
- 原因：配信先が日本だけなのでいらないと考える、キャッシュ設定を嫌う
- 症状：HTTPアクセスピーク時に待機気が律速に、CPUやディスクに余裕があるのに捌けない
- 解決方法：CloudFrontのレスポンスを体験してみる、オリジンサーバのキャッシュ設定を適切にする
ウェブアプリケーション以外のアンチパターン
ノールック明細アンチパターン
- 原因：月末の料金請求しかないと思ってる
- 症状：支払い周期のズレ、クレジットカード与信枠使い切り
- 解決方法：明細をちゃんとみる、AWSには料金を確認する機能がたくさんある、x分からない事はカスタムサービスへ
インフラ塩漬けアンチパターン
- 原因：構築した当初のままインフラの見直しが入らない
- 症状；実際の利用に比べてキャパシティの過不足を放置している
- 解決方法；1年に1度は見直す事を推奨
机上の空論アンチパターン
- 原因：サーバ発注、システムデプロイ、納品のウォータオールモデルから抜け出せない
- 症状：動作確認をしない、事前のキャパシティプランニングに時間をかけすぎる
- 解決方法：まずは小さく試してみること
まとめ
クラウドデザインパターンを活用しよう 失敗経験の共有、失敗は打開策までもっていくことが重要 失敗経験は共有することでアンチパターンとなり、とても有益な情報となる
感想
失敗経験の共有は成功経験の共有よりも有益なるのは大きく同意。自分も失敗経験はどんどん共有していきたい、失敗しないことが一番だけどね
セキュリティ的に「硬い」インフラを作ろう ― MINI Hardening Project
AWSサポートエンジニアの坪さん(@TSB_KZK)
Hardening Projectとは
- WASForumが取り組むセキュリティイベント
- 守る技術を持つエンジニアと発掘・顕彰するコンペティション
これまでに６回開催されている
競技は８時間で無防備なサーバ群をひたすら守りつつ、ECサイトの売り上げを競う
なぜMINI Hardening Projectが生まれたのか
- 場所の問題、本家は沖縄で開催されている
- 土日開催で二日間に渡って参加が必要
- セキュリテイに関連するイベントで情報が少なく難易度が高い
過去問など再現できる類のものが無い
- 会社でノウハウ共有などが難しい、再現するにも攻撃者を用意するのは難しい
東京などの需要の多い場所で土日いずれかの３時間で開催されている
- 競技、フィードバックもあるが、攻撃を体験してもらうことが主目的
競技環境
- AWSを利用
- VPCでプライベートネットワーク
- 各チームに３台のインスタンスを提供
- 脆弱なバージョンのソフトウェア、ミドルウェアを用意
- ありがちな脆弱性シナリオを用意
- デフォルト設定で起動
- アクセス制限なし
- フロントのiptablesがから
- パスワードが脆弱
評価
攻撃に関して
- 攻撃に関しては概要の説明があったが割愛
- 攻撃に気づくことは結構難しい
クローラに関して
- サービス環境のSLAを評価している
練習したい人向け
- Broken Web Application Project
- 脆弱な"やられサーバ"のイメージ(VMware, VirtualBox?)
- OWASPが提供
- OWASP ZAP
感想
久しぶりにセキュリティに関わるセッションを聞いたので、忘れかけていたことや、知らなかったことを聞けてとても良かった。影響を受けてJTF枠でMINI Hardening Projectに申し込みました。(抽選通りました！)
セキュリティインシデントを経験することは多くないと思うけど、一度体験してみると本当にセキュリティインシデントに遭遇した時や、インシデントに気づく勘も鍛えられると思うのでみなさんも是非！
HashiCorpとAtlasのインフラ管理 ― 運用に自動化を求めるのは間違っているだろうか（仮）
クリエーションラインの前佛(@zembutsu)さんのセッション
運用の変化
- 働いたら負け(刺身タンポポ、写経など手動のモチベ上がらないルーチンワークから自動化へという意)
- 〜2000年まではMRTGへの死活管理が主体
- 〜2009年はMunin, Zabbixによる時系列リソース監視へ、アクセス集中時間帯へのサービス品質維持の対応
現在は、クラウドによる時系列サービスへ
さらにコンテナ化が進むと、これまでやり方でOpsは生き残れるのだろうか
自分が使える運用ツールの最強デッキを用意することも１つの方法ではないか
物理からコンテナへ
- すべてを迅速に、一貫性を持たせて再現性を容易に
- Dockerがなぜ注目/浸透してきているのか
- 速さ
- ポータビリティ
- 再現性
- docker machine
- boot2dockerの後継
- boot2dockeと違いローカル以外にクラウド環境なども利用可能
- Docker Compose
- 旧名：fig
- 複数のDockerコンテナを１つの環境として管理する
- Dockerと仮想化システム、構成管理ツール、クラウド環境を比較するのは比較軸が異なるから向いていない
- docker.jpドメインの所有者は前佛さん、Dockerの情報を公開するサイトとして準備中
Hashicorpについて
- 技術ではなくどのように実現するのか(from Tao of Hashicorp) 手段が目的にならないようにっていうことと共通してる
- Vagrant, Packer, Serf, Consul, Terraform, Atlasなどツールの概要紹介
まとめ(意訳)
- 自分の手を動かす、自分で触る、自分で使った経験を大事にする
- ツールありきで考えない、最適なツールを必要な場面で使うこと
- 手動のルーチンワークを排除していく結果、速さ、効率性、自動化を実現できる
- そうした経験を経て蓄積したノウハウが自分の最強デッキになり今後起こりうる変化にも対応できるOpsになれる
感想
物理サーバ、仮想化、コンテナというサーバの変遷から運用を取り巻く環境の変化。DockerおよびDockerを取り巻くツール群、Hashicorpのツール説明だけではなく、なぜそれらのツールが必要となってきているのか、といった背景まで触れたボリューム満点の内容だった。ただ、ボリュームが多すぎて全体をザーッと駆け足で進む形だったのでもう少し聞きたかった。前佛さんのスライドは相変わらずネタであふれているw
全体を通しての感想
昨年初めて参加して今回は２回目でした。去年は構成管理ツールやHashicorp、OpenStack、CloudStackの概要を話すセッションが多かった気がするけど、今年は一歩踏み込んだ内容多く日々の活動に刺激になる情報をたくさん得られたので参加して本当に良かったです。
あと、セッションもさることながら、飲み物や軽食、さらにはお弁当も配布されたり、実行委員の方の事前準備に掛かる労力はとても大変だと思います。(API Meetupというコミュニティを運営していますが、３時間のmeetup + 懇親会を企画するだけでも事前準備が結構大変なんです)
来年はスピーカーとして協力出来ればと思います。実行委員会のみなさま、スタッフのみなさま、ありがとうございました！
