Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AKIBA.AWS#9 運用で楽するために設計で意識して欲しいこと
〜運用担当の視点から〜

Seigo Watanabe
July 31, 2018
1.3k

AKIBA.AWS#9 運用で楽するために設計で意識して欲しいこと
〜運用担当の視点から〜

DevOpsがもてはやされた時代から幾星霜、現在では当然のように行われているか、当然のように採用されなかったかのどちらかではないでしょうか。運用と設計は表裏一体ですが、今回は特に運用の視点から、考慮しておいて欲しいポイントについてお話しします。

※2018年7月27日に行われたクラスメソッド主催の勉強会「AKIBA.AWS #9」にて公開した内容から一部修正したスライドになります
https://dev.classmethod.jp/news/akiba-aws-180727/

Seigo Watanabe

July 31, 2018
Tweet

More Decks by Seigo Watanabe

Transcript

  1. ౉ล੟߶ ‣ `ೖࣾ ‣ "84ࣄۀຊ෦
 ΦϖϨʔγϣϯ෦ॴଐ ‣ લ৬·Ͱ͸ॴҦΠϯϑϥΤϯδχΞ ‣ ൚༻ػӡ༻ɺ*41ɺ8FCαΠτӡ༻ɹFUD

    ‣ ເݟ͕ͪͳ"84αʔϏε
 "844ZTUFNT.BOBHFS
 ʢ΋͏ͪΐͬͱ͔Ώ͍ͱ͜Ζʹख͕ಧ͍ͯཉ͍͠ʣ ࣗݾ঺հ  
  2. ʮӡ༻ʯͱ͍͏ݴ༿ͷΠϝʔδ   ੡඼EOL؅ཧ ূ໌ॻ؅ཧ υϝΠϯ؅ཧ Ϧιʔε؅ཧ IPΞυϨε؅ཧ ϧʔςΟϯά৘ใ؅ཧ ΠϯϑϥετϥΫνϟ؅ཧ

    ϑΝγϦςΟ؅ཧ ઃஔεϖʔε؅ཧ ిݯϦιʔε؅ཧ έʔϒϧࡏݿ؅ཧ ަ׵෦඼ࡏݿ؅ཧ ަ׵ػࡏݿ؅ཧ ҟԻ؅ཧ ۭௐ؅ཧ ࡞ۀ؀ڥ؅ཧ ೖୀࣨ؅ཧ ೖؗڐՄূ؅ཧ ܖ໿؅ཧ γϑτ؅ཧ ۓٸ࿈བྷ౰൪γϑτ؅ཧ ձࣾࢧڅ୺຤؅ཧ ձࣾࢧڅճઢ؅ཧ ܖ໿ઌରԠ σʔληϯλ ௨৴ճઢ Ϩϯλϧαʔό ϓϥΠϕʔτΫϥ΢υ ύϒϦοΫΫϥ΢υ υϝΠϯϨδετϥ VPN DNS ӡ༻จॻ࡞੒ ӡ༻จॻߋ৽ ӡ༻खॱॻ ෺ཧߏ੒ਤ ࿦ཧߏ੒ਤ ؅ཧද ఆৗ࡞ۀ ඇఆৗఆܕ࡞ۀ ඇఆܕ࡞ۀ ࢑ఆϦϦʔεରԠ ఆظϦϦʔεରԠ ܭըϦϦʔεରԠ ϋʔυ΢ΣΞอकରԠ ઃඋఆظอकରԠ ηΩϡϦςΟ ੬ऑੑ৘ใऩू ߋ৽ܭըཱҊ ߋ৽ܭը࣮ࢪ OSߋ৽ରԠ ϛυϧ΢ΣΞߋ৽ରԠ AbuseରԠ ඃAbuseରԠ ໰߹ͤରԠ ۤ৘ରԠ ۓٸϦϦʔεରԠ ϋʔυ΢ΣΞো֐ରԠ ϕϯμʔमཧରԠ ෦඼ަ׵ ϋϯμ෇͚ ؂ࢹઃఆ ϞχλϦϯά Ϧιʔε෼ੳ ΩϟύγςΟ༧ଌ ύϑΥʔϚϯενϡʔχϯά KPI෼ੳ ίετܭࢉ ߋ৽ίϯςϯπͷ։ൃ ௥Ճίϯςϯπͷ։ൃ ɿɹɹ ӡ༻ ؅ཧ υΩϡϝϯτ ରԠɾอक ো֐ରԠ ؂ࢹ ӡӦ
  3. ͳͥήʔϜͷ௿඼࣭ͳϩʔΧϥΠζ͸ੜ·Εͯ͠·͏ͷ͔ɻ
 όλϑϥΠɾΤϑΣΫτ͔ΒݟΔ໰୊ͷݪҼ DPOU   開発を 1 か⽉のばしても、リリース⽇はずらしたくな いのも本⾳です。予算を追加せずスケジュールを延期 できないとなると、どこかのプロセスを縮めなければ

    ならない。そこで短縮の対象となるのが、ローカライ ズの作業です。ローカライズ作業はまだスタートして いないにもかかわらず、最初から 1 か⽉のカットした 状態でスタートすることになります。 https://jp.automaton.am/articles/localizetalk/20180715-72007/ l
  4. DevOpsは基本概念 (cont.)   ‣SRE = DevOpsを前提にエラーバジェットの考え⽅を加えたもの ‣DevSecOps = Securityの⼤切さを強調したもの

    ‣コンテナ(Docker以降) = DevOpsの強⼒な武器 ‣クラウドインフラ, FaaS, CaaS, Serverless = 同上 ‣⾃動化・Infrastructure as Code = 同上 ‣Immutable Infrastructure, B/G Deployment = 同上 ‣CI/CD (以下略 https://www.irasutoya.com/
  5. 稼働率   A = E[uptime] E[uptime] + E[downtime] ‣uptime

    と downtime で計算 ‣downtime は 1回あたりの平均復旧時間(MTTR)とその回数の積 ‣MTTRが短ければ、稼働率を落とさずに回数を増やして良い︕ ‣ぶっちゃけMTTRが0.1秒以下だったら落とし放題では︖︖(極論 ‣短いダウンタイムとリトライ復旧は、遅いことと区別がつかない(ユーザ⽬線) ‣無視して良いわけでは無い(別の障害の兆候かも︖)
  6. まとめ︓運⽤で楽するために設計で意識して欲しいこと   ‣運⽤ ≠ オペレーション ‣ リリース後にやるべきことは多岐に及びます ‣ ⻑い開発サイクルは、下流に負荷が集中しがちとなる(構造的な問題)

    ‣Well-Architected な考え⽅ ‣ 早いサイクルでの構築・デプロイ、⾜りない機能の追加実装 ‣ 開発と運⽤の強い連携 = DevOps ‣エラーバジェット的な考え⽅ ‣ 稼働率を落とさずリリース頻度を上げるために ‣フェイルセーフ ‣ 異常が発⽣しても障害を起こさない設計 ‣ 「ヒューマンエラーというエラーはない」
  7. そのための道具   ‣コンテナ(Docker以降) <- ECS, EKS ‣マネージドインフラ、Serverless <- ‣SaaS

    <- ‣UI/UX ‣適切な権限設定 <- IAM ‣CI/CD <- Code兄弟 ‣機械化・⾃動化 <- ‣ロギング・モニタリング <- CloudWatch