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

E39a62a5c1f1829cc6ce0ec642424947?s=47 Seigo Watanabe
July 31, 2018
960

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

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

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

E39a62a5c1f1829cc6ce0ec642424947?s=128

Seigo Watanabe

July 31, 2018
Tweet

Transcript

  1. #akibaaws

  2. ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ  ",*#""84Ԡ༻ฤ

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

    ‣ ເݟ͕ͪͳ"84αʔϏε
 "844ZTUFNT.BOBHFS
 ʢ΋͏ͪΐͬͱ͔Ώ͍ͱ͜Ζʹख͕ಧ͍ͯཉ͍͠ʣ ࣗݾ঺հ  
  4.   ӡ༻JTԿ

  5. ʮӡ༻ʯͱ͍͏ݴ༿ͷΠϝʔδ   ੡඼EOL؅ཧ ূ໌ॻ؅ཧ υϝΠϯ؅ཧ Ϧιʔε؅ཧ IPΞυϨε؅ཧ ϧʔςΟϯά৘ใ؅ཧ ΠϯϑϥετϥΫνϟ؅ཧ

    ϑΝγϦςΟ؅ཧ ઃஔεϖʔε؅ཧ ిݯϦιʔε؅ཧ έʔϒϧࡏݿ؅ཧ ަ׵෦඼ࡏݿ؅ཧ ަ׵ػࡏݿ؅ཧ ҟԻ؅ཧ ۭௐ؅ཧ ࡞ۀ؀ڥ؅ཧ ೖୀࣨ؅ཧ ೖؗڐՄূ؅ཧ ܖ໿؅ཧ γϑτ؅ཧ ۓٸ࿈བྷ౰൪γϑτ؅ཧ ձࣾࢧڅ୺຤؅ཧ ձࣾࢧڅճઢ؅ཧ ܖ໿ઌରԠ σʔληϯλ ௨৴ճઢ Ϩϯλϧαʔό ϓϥΠϕʔτΫϥ΢υ ύϒϦοΫΫϥ΢υ υϝΠϯϨδετϥ VPN DNS ӡ༻จॻ࡞੒ ӡ༻จॻߋ৽ ӡ༻खॱॻ ෺ཧߏ੒ਤ ࿦ཧߏ੒ਤ ؅ཧද ఆৗ࡞ۀ ඇఆৗఆܕ࡞ۀ ඇఆܕ࡞ۀ ࢑ఆϦϦʔεରԠ ఆظϦϦʔεରԠ ܭըϦϦʔεରԠ ϋʔυ΢ΣΞอकରԠ ઃඋఆظอकରԠ ηΩϡϦςΟ ੬ऑੑ৘ใऩू ߋ৽ܭըཱҊ ߋ৽ܭը࣮ࢪ OSߋ৽ରԠ ϛυϧ΢ΣΞߋ৽ରԠ AbuseରԠ ඃAbuseରԠ ໰߹ͤରԠ ۤ৘ରԠ ۓٸϦϦʔεରԠ ϋʔυ΢ΣΞো֐ରԠ ϕϯμʔमཧରԠ ෦඼ަ׵ ϋϯμ෇͚ ؂ࢹઃఆ ϞχλϦϯά Ϧιʔε෼ੳ ΩϟύγςΟ༧ଌ ύϑΥʔϚϯενϡʔχϯά KPI෼ੳ ίετܭࢉ ߋ৽ίϯςϯπͷ։ൃ ௥Ճίϯςϯπͷ։ൃ ɿɹɹ ӡ༻ ؅ཧ υΩϡϝϯτ ରԠɾอक ো֐ରԠ ؂ࢹ ӡӦ
  6. ӡ༻˓˓˓   ӡ༻ ≠ ΦϖϨʔγϣϯ

  7. τϥσΟγϣφϧ΢ΥʔλʔϑΥʔϧΠϝʔδ   http://01.gatag.net/0003159-free-photo/ ※ը૾͸ΠϝʔδͰ͢

  8. τϥσΟγϣφϧ։ൃΠϝʔδ   اը ։ൃ ӡ༻ https://www.irasutoya.com/ ※ը૾͸ΠϝʔδͰ͢

  9. τϥσΟγϣφϧεέδϡʔϧ஗ԆΠϝʔδ   https://www.irasutoya.com/ https://www.data.jma.go.jp/svd/eqev/data/tsunami/generation.html ※ը૾͸ΠϝʔδͰ͢

  10. スケジュール遅延することの影響   ‣運⽤のための準備ができない ‣ドキュメント未整備が原因でいろんなことが ‣運⽤設計不⾜であんなことやこんなことまで ‣「いざとなったら運⽤でカバー」というパワーワード ‣リリース品質の低下 = 障害が起こりやすくなる

    ‣関係者と連絡が取りづらくなる ‣・・・ https://www.irasutoya.com/ ※ը૾͸ΠϝʔδͰ͢
  11. ؓ࿩ٳ୊   ゲームにおける ローカライズ (翻訳・多⾔語化) 運⽤ is 何

  12. ͳͥήʔϜͷ௿඼࣭ͳϩʔΧϥΠζ͸ੜ·Εͯ͠·͏ͷ͔ɻ
 όλϑϥΠɾΤϑΣΫτ͔ΒݟΔ໰୊ͷݪҼ   https://jp.automaton.am/articles/localizetalk/20180715-72007/

  13. ͳͥήʔϜͷ௿඼࣭ͳϩʔΧϥΠζ͸ੜ·Εͯ͠·͏ͷ͔ɻ
 όλϑϥΠɾΤϑΣΫτ͔ΒݟΔ໰୊ͷݪҼ DPOU   開発を 1 か⽉のばしても、リリース⽇はずらしたくな いのも本⾳です。予算を追加せずスケジュールを延期 できないとなると、どこかのプロセスを縮めなければ

    ならない。そこで短縮の対象となるのが、ローカライ ズの作業です。ローカライズ作業はまだスタートして いないにもかかわらず、最初から 1 か⽉のカットした 状態でスタートすることになります。 https://jp.automaton.am/articles/localizetalk/20180715-72007/ l
  14. τϥσΟγϣφϧൺᄻදݱɿՆٳΈͷ॓୊   https://www.irasutoya.com/ 7/20 8/31

  15. ͻΏͻΐ͏͛Μɿ   https://www.google.com/search?q=%E3%81%BC%E3%81%8F%E3%81%AE%E3%81%AA%E3%81%A4%E3%82%84%E3%81%99%E3%81%BF+8%E6%9C%8832%E6%97%A5

  16. ઌਓͷ஌ܙ   http://rinjinyabai.com/archives/34850769.html

  17. %FW0QT     https://ja.wikipedia.org/wiki/DevOps

  18. %FW0QT    DPOU   https://ja.wikipedia.org/wiki/DevOps

  19. %FW0QT͸جຊ֓೦   https://www.irasutoya.com/

  20. 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/
  21. None
  22. https://ja.wikipedia.org/wiki/DevOps

  23. λΠτϧʢ࠶ܝʣ    ",*#""84Ԡ༻ฤ ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ

  24. ݁࿦   8"࣮ફ͍ͯͩ͘͠͞ https://store.line.me/stickershop/product/3998375

  25. %FWFMPQFST*0ʢએ఻ʣ  

  26. None
  27. https://store.line.me/stickershop/product/3998375

  28. λΠτϧʢ࠶ܝʣ    ",*#""84Ԡ༻ฤ ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ

  29.   ΤϥʔόδΣοτతͳߟ͑ํ

  30. エラーバジェット的な考え⽅   ‣「悲観的に設計(準備)し、楽観的に運⽤(実⾏)せよ」 ‣後戻り出来ない場⾯での格⾔ ‣考え⽅⾃体は⼤切だが、ある程度のエラーを許容する ことでいろいろなものが短縮できる ‣過度にエラーを恐れずに新機能をリリースできる ‣運⽤してて⾜りないものがあったら実装しちゃいなよ︕

  31. 稼働率   A = E[uptime] E[uptime] + E[downtime] ‣uptime

    と downtime で計算 ‣downtime は 1回あたりの平均復旧時間(MTTR)とその回数の積 ‣MTTRが短ければ、稼働率を落とさずに回数を増やして良い︕ ‣ぶっちゃけMTTRが0.1秒以下だったら落とし放題では︖︖(極論 ‣短いダウンタイムとリトライ復旧は、遅いことと区別がつかない(ユーザ⽬線) ‣無視して良いわけでは無い(別の障害の兆候かも︖)
  32.   ϑΣΠϧηʔϑ

  33. ϑΣΠϧηʔϑͱ͍͏ઃܭࢥ૝   ‣異常が発⽣(フェイル)しても安全(セーフ)である ‣データロスが起きない ‣リトライで復元する etc... ‣よく⾔われる例 = 踏切の遮断機、⽊こりは斜⾯の上から⽊を切る etc... ‣異常系の対応⼿順・体制が整備されていることも広義の「セーフ」

    ‣フールプルーフ = そもそも異常な操作ができない(権限、UI) ‣フォルトトレラント = 障害発⽣時でも縮退運転で継続 = 冗⻑性
  34. ࢀߟɿηʔϑ΢ΣΞ   ‣事故には必ず原因がある ‣ヒューマンエラーというエラーはない ‣ヒューマンエラーは必ず発⽣するので、 それを⾒込んでいないことこそがエラー https://www.shoeisha.co.jp/book/detail/9784798116846

  35. まとめ︓運⽤で楽するために設計で意識して欲しいこと   ‣運⽤ ≠ オペレーション ‣ リリース後にやるべきことは多岐に及びます ‣ ⻑い開発サイクルは、下流に負荷が集中しがちとなる(構造的な問題)

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

    ‣ロギング・モニタリング 等々
  37. そのための道具   ‣コンテナ(Docker以降) <- ECS, EKS ‣マネージドインフラ、Serverless <- ‣SaaS

    <- ‣UI/UX ‣適切な権限設定 <- IAM ‣CI/CD <- Code兄弟 ‣機械化・⾃動化 <- ‣ロギング・モニタリング <- CloudWatch
  38. ٹੈओ   http://rinjinyabai.com/archives/34850769.html

  39. None