20150706 web-operation-training

Transcript

• 1. WEB OPERATION 2015年 GMOペパボ新卒エンジニア研修 Webオペレーション研修イントロダクション
• 2. アジェンダ Webオペレーション研修 … おさらい Webオペレーションとは … 言葉が内包するもの 研修における位置付け … 何を学んでほしいのか Nyahについて … ペパボの仮想インフラ基盤の紹介 研修の進め方 … ゴール、チーム、ルール、見積りと計画
• 3. 月 火 水 木 金 10:00 読書会 11:00 基礎研修 13:00 昼 14:00 基礎研修 17:00 CK 研修 CK 基礎研修 18:00 リフレク＆シェアリング・次回目標・日報 Webアプリケーションを 正常稼働 させるために必要な知識の修得 (7/6∼8/7) Webオペレーション研修 Web開発 モバイル Web
 オペレーション http://www.slideshare.net/hifumis/20150608-thetaoofpepaboengineer-49152106
• 4. Webオペレーションとは 言葉が内包するもの
• 5. 役割、期待、実態から見るWebオペレーション Webオペレーションとは 1. 役割：どのような職種か 2. 期待：必要とされている知識領域 3. 実態：どのように業務を遂行しているのか
• 6. 1. 役割：どのような職種か Webオペレーションとは • Webアプリケーションを正常稼働さ せるのに必要な知識や経験を備えた 専門職種 • ペパボでは、「インフラエンジニア」 が主にこの領域を担当 ※ちなみに表紙の魚は「バラクーダ（オニカマス）」らしい
• 7. 2. 期待：必要とされている知識領域 Webオペレーションとは ネットワーク・ルーティング・スイッチング・ファイアウォール・負 荷分散・高可用性・障害復旧・TCPやUDPのサービス・NOCの管 理・ハードウェア仕様・複数のUnix環境・複数のウェブサーバ技術・ キャッシュ技術・データベース技術・ストレージインフラ・暗号技術・ アルゴリズム・傾向分析・キャパシティ計画立案… 『ウェブオペレーション 1章』より
• 8. 3. 実態：どのように業務を遂行しているのか Webオペレーションとは • 先の知識領域を1人で全部やるのは大変 • ペパボでは、東京のインフラグループ・ 福岡のインフラチームが横断的に活動 • 得意な分野を牽引し、得意な分野で助け 合い、連携して業務を遂行している
• 9. 3. 実態：どのように業務を遂行しているのか（例として） Webオペレーションとは
• 10. ペパボにおける「インフラG/T」と「情シス」の違いは知ってる？ Webオペレーションとは • サービスのインフラを支えているのがインフラG/T • ロリポップ！、ヘテムル、カラーミー、… • ペパボスタッフのインフラを支えているのが情シス • PC機器類、社内ネットワーク、社内インフラ、… ※完全にこの通りでは無いが、概形として。
• 11. まとめ：役割、期待、実態から見るWebオペレーション Webオペレーションとは 1. 役割：Webアプリを正常稼働させるのに必要な知識や経 験を備えた専門職種 2. 期待：必要とされている知識領域は多岐にわたる（最近 は仮想化・分散化技術等も） 3. 実態：ペパボではインフラ部隊が問題解決にあたる
• 12. 研修における位置付け 何を学んでほしいのか
• 13. 何を学んでほしいのか 研修における位置付け • エンジニア全員に持ってほしい能力 • ペパボの強みを知る • 科学ではなく技芸
• 14. エンジニア全員に持ってほしい能力 研修における位置付け • 開発者もメトリクスは見るし、運 用者もコードは書く時代* • 「何かが来た」** ときに、迅速か つ適切な対応をするには、Webオ ペレーション能力も必要 * http://www.slideshare.net/studio3104_com/yapc-asia-2014
 ** https://speakerdeck.com/inouetakuya/ec-performance-testing
• 15. エンジニア全員に持ってほしい能力：対話と協調の大切さ Webオペレーションとは If non-communicative & non-collaborative… http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr It’s not my machines,
 it’s your code! It’s not my code,
 it’s your machines!
• 16. エンジニア全員に持ってほしい能力：視野を更に広げよう Webオペレーションとは • エンジニアは自らの職能を越えた動きを推奨されている* • 研修を通しての繰り返しになるが、研修の3つの軸を学 ぶことで、広く深い知識や経験を手に入れてほしい * https://speakerdeck.com/kentaro/engineering-in-gmo-pepabo-inc?slide=15
• 17. ペパボの強みを知る Webオペレーションとは http://www.slideshare.net/hifumis/20150608-thetaoofpepaboengineer-49152106/27
• 18. 科学ではなく技芸 Webオペレーションとは • 正規の教育や資格、標準、「正しい方法」はない • プロフェッショナルの知識や経験、ツール、プロセスが 「Webオペレーション」という技芸になっていった • 研修というサポート環境のもとで、実践的な「型」を身 につけてほしい
• 19. まとめ：何を学んでほしいのか Webオペレーションとは • 開発・運用はエンジニアに修得してほしいスキル • Webオペレーションはペパボの強みの1つ • プロフェッショナルの技術から、実践的な「型」を学ぶ
• 20. Nyahについて ペパボの仮想インフラ基盤の紹介
• 21. OpenStackをベースとしたペパボの仮想インフラ基盤 (IaaS) 次世代開発環境としてのNyah • サービスに必要なインフラ基盤を、 仮想化技術にもとづいて提供 • 作りたいものをバーンと作って公 開できる環境 http://www.slideshare.net/ume3_/pb-tc01-bob001
• 22. Nyahが無かった頃の開発環境：Maglica Episode Zero • https://github.com/mizzy/maglica • http://www.slideshare.net/mizzy/ maglica-techkayac • GH:E tech/maglica-usage
• 23. Nyah説明会・ハンズオン • @ume3_ (ボブさん) 主導 • 本日7/6 14:00-16:00 • ＠放送室
• 24. まとめ Nyahについて • サービスに必要なインフラ基盤を仮想化技術にもとづい て提供してくれる君 • 昔（今も現役だけど）はmaglicaを使っていた • 午後にハンズオンを予定
• 25. 研修の進め方 ゴール、チーム、グランドルール、見積りと計画について
• 26. グランドルール 見積りと計画 チーム ゴール
• 27. アプリが「動く」インフラを、ステップ・バイ・ステップで成長させる ゴール
• 28. アプリが「動く」インフラを、ステップ・バイ・ステップで成長させる ゴール manual install infra as code transfer high availability test Vagrant編 Nyah編
• 29. Vagrant編 VagrantにRails Tutorialのアプリケーションが動く環境を作る
• 30. VagrantにRails Tutorialで作ったWebアプリケーションが動く環境を作る ステップ：manual install • パッケージマネージャやエディタ などを駆使して頑張る • gistなどに手順をメモしておく ※historyコマンドは便利
• 31. rails s -b 0.0.0.0 -p 80 して、VM上のWebアプリにアクセス可能にする ステップ：manual install VM —————— app, db rails, mysql (or mariadb)
• 32. ペパボのプロダクションでも使われている構成にジャンプアップする ステップ：manual install VM —————— app, db nginx + unicorn (socket), mysql
• 33. やること ステップ：manual install 1. VagrantでVM (CentOS 7) を作る 2. Rails Tutorialで作ったWebアプリ をVM上で動かす (rails server) 3. nginx + unicornに切り替える ※出来る人は2を飛ばしても良い
• 34. サーバは意図通りに動いてますか？それをどうやって保証しますか？ ステップ：test • パッケージなに入れた？ • 設定ファイルを変更した？ • サービスは起動した？ • サービスは自動起動する？ • ポートはリスンしてる？ • 適切な権限を与えた？ • 実行ユーザは存在する？ • サービスは動作してる？
• 35. サーバの構成・状態をテストしよう ステップ：test ✓パッケージなに入れた？ ✓設定ファイルを変更した？ ✓サービスは起動した？ ✓サービスは自動起動する？ ✓ポートはリスンしてる？ ✓適切な権限を与えた？ ✓実行ユーザは存在する？ ✓サービスは動作してる？
• 36. 1st: Serverspec ステップ：test(ing tools) • サーバの状態をコードにより自動 的にテストするためのツール http://serverspec.org https://github.com/serverspec
• 37. 2nd: Infrataster ステップ：test(ing tools) • サーバの振る舞いをテストするた めのツール • 出来たらやってみよう https://github.com/ryotarai/infrataster
• 38. やること ステップ：test 1. Serverspecをインストール 2. サーバのテストを書く 3. 余裕があればInfratasterでのテ ストも導入する
• 39. Infrastructure as Code : コードとしてのインフラ ステップ：infra as code package 'nginx' do action :install end service 'nginx' do action [:enable, :start] end
• 40. Configuration management tool : 構成管理ツール ステップ：infra as code • インフラの状態を構造化 • プラットフォーム間の差異を吸収 • Puppet, Chef, Ansible, Itamae…
• 41. 構成管理ツールとして、Itamaeを使っていきましょう ステップ：infra as code • https://github.com/itamae-kitchen/itamae • 構成管理ツールの学習そのものは研修 の本質からやや逸れる • Web開発研修でRubyを扱った • Itamaeはシンプル、軽量、Ruby DSL
• 42. やること ステップ：infra as code 1. Itamaeをインストールする 2. manual installの手順をコード化する 3. 新規VMにItamaeを実行する 4. テストをオールグリーンにする ※3と4は往復することもあり得る
• 43. やることまとめ Vagrant編 1. Web開発研修で作成したRailsアプ リを、Vagrantで動かす 2. Serverspec, Infratasterなどでサーバ の構成・振る舞いをテストする 3. Itamaeでサーバ構成をコード化する
• 44. Nyah編
• 45. WebアプリをNyahで動かせるようにする ステップ：transfer 1. NyahのVMを1個作る 2. Itamaeでサーバ構築 3. テストをオールグリーンにする
• 46. VM —————— app, db 可用性に対する課題 ステップ：high availability • 1サーバで動いているものが多い • リソースの食い合い • どのパッケージがどのシステムに 必要なのか分かりにくい複雑な依 存関係
• 47. VM —————— a role 可用性に対する課題 : 役割ごとにVMを用意する ステップ：high availability • 再利用できるネットワークアクセ ス可能な単位 (サービス)* に分割 • 構成の変更に伴うコードや設定の 修正・変更 VM —————— a role VM —————— a role VM —————— a role VM —————— a role * 「ウェブオペレーション 5章 コードとしてのインフラ」より
• 48. 可用性に対する課題 : 役割に対して適切なスペックを与える ステップ：high availability • ストレージ、メモリ、CPU、… • それぞれの役割に対して適切な flavor (OpenStackの仮想ハード ウェアの名称) を選択する VM —————— a role VM —————— a role VM —————— a role VM —————— a role VM —————— a role
• 49. Normal stage まずはここから
• 50. app/dbの分離 ステップ：high availability app db nginx + unicorn (socket) mysql
• 51. dbのレプリケーション (backup, redundancy) ステップ：high availability app db (master) db (repl) nginx + unicorn (socket) mysql
• 52. Grand stage より本格的なインフラ構成をめざして
• 53. unicorn リバースプロキシの導入 ステップ：high availability app db (master) db (repl) reverse proxynginx upstream (TCP)
• 54. appサーバの冗長化 (scale out) app ステップ：high availability db (master) db (repl) reverse proxy app nginx unicorn upstream (TCP)
• 55. セッションストレージの分離 app ステップ：high availability db (master) db (repl) reverse proxy app session storage redis, memcached
• 56. Extra stage 余裕があればやってみよう
• 57. 監視・メトリクスの導入 (monitoring) app ステップ：high availability db (master) db (repl) reverse proxy app session storage Nagios sensu consul-alert mackerel.io Munin New Relic
• 58. Legendary stage 研修よりはるか高みへ
• 59. 研修としてはオーバクオリティ… (この辺から high っぽくなってくる) app ステップ：high availability db (master) slave proxy app session (active) proxy load balancer lvs + keepalived, serf + haproxy, … reference to slave session (standby) lb redis sentinel, … lb lb
• 60. やること (Extra, Legendaryはおかわり案件) ステップ：high availability 1. app/dbを分離 2. dbの冗長化 3. リバースプロキシの導入 4. appの冗長化 5. セッションサーバの分離
• 61. サーバ移行、冗長化、オーケストレーション Nyah編 1. Nyah上のVMでアプリケーショ ンを動かす 2. 役割ごとにVMを分割し、耐障 害性を向上させる
• 62. ゴール グランドルール 見積りと計画 チーム
• 63. 前提 : ノウハウを共通化させる必要性について チーム • 構成管理ツールやデプロイツールの選択肢は多様 • サービス特性に応じたツール選択は必須 • 複数人での活動に耐えうる運用の確立は重要
• 64. 2人1組になってインフラを設計、構築、運用していきましょう チーム • リポジトリ、コード、ドキュメント、Issueの活用 • 外部公開出来ない情報も出るため、作業場はGH:Eで🙇
• 65. Shuffle! チーム • 1週間ごとにチームは交代 • 他の人が手がけた運用に触れる経験 • その運用を引き継ぐも刷新するも自由、ただし対話とい うプロセスはとっても大切
• 66. 「test」のフェーズからチーム作業を開始しましょう チーム manual install infra as code transfer high availability test
• 67. 各フェーズで相談しなければならないことの例 チーム • お互いのmanual installの作業内容に問題は無いか？ • testの内容はこれで十分か？ • Itamae recipeの設計内容はこれで良いか？ • デプロイツールはどうする？
• 68. まとめ チーム • 「test」フェーズから、2人1組のチームを作って運用する • チームは1週間毎に交代する • それぞれのフェーズで運用方法を確かめ合っていく • github.com ではなくGH:Eに新規リポジトリを作る
• 69. ゴール 見積りと計画 チーム グランドルール
• 70. BDD (Bosukete Driven Development) は変わらず グランドルール http://www.slideshare.net/hifumis/20150609-webdevelopmenttraining/26
• 71. ゴール チーム グランドルール 見積りと計画
• 72. 基本的なプロセスはWeb開発研修と同じだが、難易度は増した 見積りと計画 • 「やること」の幅が広がった • 「やること」の複雑さが増した • 見積りの単位はストーリーポイン ト？理想時間？ https://speakerdeck.com/kenchan/web-dev-training-introduction
• 73. 使える時間と場所 見積りと計画 • 7/6 16:00-17:00 音楽室 • 7/7 10:00-12:00 美術室
• 74. まとめ 見積りと計画 • Web開発研修と同じやり方を再び実践 • 前回よりも難易度は高い • 3時間程度でやりましょう
• 75. まとめ Webオペレーション研修 … 7/6∼8/7に実施する基礎研修の1つ Webオペレーションとは … Webアプリを正常稼働させるための多岐 にわたる知識や経験を備え、課題解決にあたる専門職
 研修における位置付け … Webオペレーションの型をプロから学ぼう Nyahについて … OpenStackをベースとしたペパボのIaaS 研修の進め方 … さいきょうのインフラをチームでつくろう
• 76. Appendix
• 77. DevOps • It's not abstraction. • It's not even "infrastructure as code". • It's not any single tool. • It's not about provisioning. • It's not about deployment. • It's not about a job description or position. • It's also not about the cloud, except for the part where deployment and provisioning of infrastructure gets easier to understand for groups of people who historically wouldn't have touched that part of the business. • It *is* about the collaborative and communicative culture and the tools and process that arise from that culture. Nothing more. http://www.rationalsurvivability.com/blog/2010/05/incomplete-thought-the-devops-disconnect/#comment-3375
• 78. Provisioning Toolchain Provisioning Toolchain by Lee Thompson (Velocity 2010), サーバプロビジョニングのこれまでとこれから (デブサミ2014) より作成 Application Service Orchestration System Configuration OS install Cloud or VM Image Launch Capistrano Fabric Serf Consul Puppet Chef Itamae Kickstart Cobbler EC2 OpenStack Orchestration Configuration Bootstrapping Ansible
• 79. Test Driven Infrastructure Virtualization and Cloud Computing have made it easy to procure and provision hardware and virtual servers. But with this flexibility comes scale and complexity, and managing our virtual estates has become increasingly difficult. Using techniques more familiar in the software development world such as TDD, BDD and CI offers an approach to managing this complexity and gives us the confidence to make changes to our infrastructure in a safe, repeatable and automatable manner. Provisioning testing tools, like rspec-puppet, Test Kitchen and serverspec, are available for most platforms. http://www.thoughtworks.com/radar/techniques/provisioning-testing
• 80. Nightmare microservices Migrating to Microservices by @adrianco GOTO Berlin 2014 “Death Star” Architecture Diagrams Netflix Gilt Groupe (12 of 450) Twitter As visualized by Appdynamics, Boundary.com and Twitter internal tools