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

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

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

Transcript

1. #akibaaws
2. ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ 
   ",*#""84
   
   Ԡ༻ฤ
3. ౉ล੟߶
   ‣ `ೖࣾ
   ‣ "84ࣄۀຊ෦
 ΦϖϨʔγϣϯ෦ॴଐ
   ‣ લ৬·Ͱ͸ॴҦΠϯϑϥΤϯδχΞ
   ‣ ൚༻ػӡ༻ɺ*41ɺ8FCαΠτӡ༻ɹFUD
   
   ‣ ເݟ͕ͪͳ"84αʔϏε
 "84
   4ZTUFNT
   .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/
22. https://ja.wikipedia.org/wiki/DevOps
23. λΠτϧʢ࠶ܝʣ
     
    ",*#""84
    
    Ԡ༻ฤ ӡ༻Ͱָ͢ΔͨΊʹઃܭͰҙࣝͯ͠ཉ͍͜͠ͱ
 ʙӡ༻୲౰ͷࢹ఺͔Βʙ
24. ݁࿦
     8"࣮ફ͍ͯͩ͘͠͞ https://store.line.me/stickershop/product/3998375
25. %FWFMPQFST*0ʢએ఻ʣ
    
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