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

はてなリモートインターンシップ2023 インフラ講義資料

Hatena
October 18, 2023

はてなリモートインターンシップ2023 インフラ講義資料

Hatena

October 18, 2023
Tweet

More Decks by Hatena

Other Decks in Programming

Transcript

  1. Web αʔϏε
    Πϯϑϥೖ໳
    #hatenaintern)*)+
    !

    View full-size slide

  2. この講義の⽬的
    以下を達成することを⽬的としています
    • Webサービスを開発運⽤するときのインフラについて雰囲気を
    つかむ
    • インフラエンジニアでなくてもいざとなったら向き合う覚悟を
    完了する
    !

    View full-size slide

  3. 前提
    ある程度パブリッククラウド環境(AWS)を想定した説明があり
    ます
    パブリッククラウド環境の重要な特性は以下です
    • オンデマンドでリソースの調達ができる
    • インフラの操作を⾏うためのAPIが⽤意されており、プログラム
    から操作できる
    !

    View full-size slide

  4. 話の流れ
    • 最初にざっくりした全体の話
    • 信頼性のあるWebサービスを作るための基本的なテクニック
    • 現代のさまざまなプラクティスにどう接続しているか
    !

    View full-size slide

  5. インフラ
    !

    View full-size slide

  6. インフラとは
    インフラとは、社会や経済、あるいは国
    ⺠⽣活が拠って⽴つ基盤となる、必要不
    可⽋な施設やサービス、機関、制度、仕
    組みなどのこと。“infrastructure” は
    「基盤」「下部構造」などの意味を持つ
    英単語で、外来語としては「インフラ」
    という略語が定着している。
    — https://e-words.jp/w/インフラ.html
    !

    View full-size slide

  7. System - ( Application + Data ) = Infra
    !

    View full-size slide

  8. システムを利⽤したワークフローな
    どはシステムに含まない
    例えばユーザーサポートチームの業務は「システムのインフラ」ではない
    !

    View full-size slide

  9. システム全体
    機能
    • アプリケーション
    • データベース、KVS、全⽂検
    索、ストレージ、DNSなど
    周辺サービス
    • ネットワーク
    ⾮機能
    • バックアップやログ記録
    • テスト、ビルド、デプロイ
    のパイプライン
    • モニタリング
    !

    View full-size slide

  10. 影響が強い3つの⼒(フォース)
    • 信頼性、⽣産性、コスト
    • トレードオフ関係ではない
    • 緊張関係にある
    +--------------+
    | |
    | Reliability +---------------+
    | | |
    +------+-------+ +-----+------+
    | | |
    | | Cost |
    | | |
    +------+-------+ +-----+------+
    | | |
    | Productivity +---------------+
    | |
    +--------------+
    ( ᯣ _ ᯣ ) !!" Monitoring
    !"

    View full-size slide

  11. モニタリング(Monitoring)
    「計測できないものは制御できない」
    — トム‧デマルコ
    !!

    View full-size slide

  12. 信頼性、⽣産性、コストのうちで
    信頼性(その中で特に可⽤性)の話
    !"

    View full-size slide

  13. 信頼性
    ちゃんと動くかどうか
    • セキュリティやガバナンスの要件を満たし
    • 可⽤性要件が満たされているか?(性能要件とか接続性)
    !"

    View full-size slide

  14. サイトの信頼性は、エンドユーザーに利⽤可能な状態
    となった後にアプリケーションが提供するサービスの
    安定性と質を表します。技術的な問題が検出されなか
    った場合、ソフトウェアメンテナンスがソフトウェア
    の信頼性に影響を及ぼすことがあります。例えば、デ
    ベロッパーが新しい変更を加えると、意図せずに既存
    のアプリケーションに影響を及ぼし、特定のユースケ
    ースでクラッシュを引き起こす可能性があります。
    (https://aws.amazon.com/jp/what-is/sre)
    !"

    View full-size slide

  15. 可⽤性(Availability)
    • 稼働率
    • Քಇ࣌ؒ/ܭଌ࣌ؒ で表される
    • ⽬標として⽴てる場合は 99.999% "Five nines" のように9の数を数える
    • 99.5%だと"two and half nines"
    • 99.999% は 1年で5分間のダウンタイムを許容することになる
    • 1ヶ⽉で合計30秒落ちると可⽤性⽬標を下回る、ということになる
    !"

    View full-size slide

  16. X-Nines と許容可能ダウンタイム
    可⽤性⽬標 365⽇ 30⽇ 28⽇ 14⽇ 7⽇
    00 (3N) 3.65 ⽇ 7.2 時間 6.72 時間 3.36 時間 1.68時間
    00.0 (9N) 8.76 時間 43.2 分 40.32 分 20.16 分 10.08 分
    00.0; 1.752 時間 8.64 分 8.064 分 4.032 分 2.016 分
    00.00 (00.000 (=N) 5.256 分 25.92 秒 24.192 秒 12.096 秒 6.048 秒
    !"

    View full-size slide

  17. Rolling Window vs Calendar Window
    「7⽇間の可⽤性⽬標99%です」といったとき、
    • この「7⽇間」を、
    • 「⽉曜から⽇曜まで」などと決めるのが Calendar Window
    • 「その時点から7⽇前まで」などと決めるのが Rolling
    Window (Sliding Window)
    !"

    View full-size slide

  18. 複合システムの可⽤性
    • シンプルなシステム構成を考える
    • すべてのコンポーネントの単独の可⽤性が 99.9% だとすると...
    +-----+ +-----+ +-----+ +-----+
    | | | | | | | |
    | CDN +!!" LB +!!"+ App +!!"+ DB |
    | | | | | | | |
    +-----+ +-----+ +-----+ +-----+
    99.9% 99.9% 99.9% 99.9%
    # 0.999 * 0.999 * 0.999 * 0.999 = 0.996
    全体では 99.6%
    99.9%を下回ってしまった!
    !"

    View full-size slide

  19. ⾼可⽤なシステムを作る
    !"

    View full-size slide

  20. どうやって?
    !"

    View full-size slide

  21. 冗⻑化と負荷分散、スケールアップ/ダウン
    説明
    冗⻑化 1つのコンポーネントがダウンしても他のコンポーネ
    ントが機能するようにする
    ⾃動回復と⼤きな扱いの差はない
    ⽔平負荷分散(⽔平分散) 同種の仕事を複数のコンポーネントで処理する
    分散数を増やすのをスケールアウト、分散数を減ら
    すのをスケールインと呼ぶ
    垂直負荷分散 ⼀つの仕事を分割して複数のコンポーネントで処理
    する
    スケールアップ/ダウン より性能の⾼い/低い実⾏環境へ変更すること
    !"

    View full-size slide

  22. SPOF / 単⼀障害点
    • ⼀箇所が壊れたら全体が障害となる場所のこと
    • 冗⻑化 = ⾮SPOF化
    !!

    View full-size slide

  23. 監視と回復性
    問題が起きた際に素早く回復できるようにする
    • 問題を素早く検出する
    • ⾃動的に復旧する
    • 負荷の増⼤における⾃動的なスケールや、サーバーの応答不良に
    応じた⾃動的な再起動などは良い回復性の例
    • ⾃動化できない場合、⼈間がアラートを拾って対応する、というワ
    ークフローを組むことになる
    !"

    View full-size slide

  24. システムの構成要素について、冗⻑
    化や負荷分散をうまく考慮し、
    SPOFがなるべくないようにする
    また問題が発⽣しても素早く回復で
    きるようにする
    !"

    View full-size slide

  25. 伝統的な構成の⼯夫
    • 素朴なアーキテクチャに⾒える
    • 様々な要求に応える⼯夫が詰まっている
    +-----+
    | CDN |
    +!"+!"+
    |
    +!"+!"+
    | LB | ( reverse proxy )
    +!"+!"+
    |
    +!"+!"+
    | APP |
    +!"+!"+
    +--------+
    +!"+!"+ +!"+!"+
    | DB | | KVS |
    +-----+ +-----+
    !"

    View full-size slide

  26. アプリケーション
    !"

    View full-size slide

  27. アプリケーションは横に並べられるようにす

    • アプリケーションはもっとも頻繁に変更されるた
    め、独⽴して変更できるように分割する
    • ユーザー数増加などで必要な計算能⼒が変動しや
    すい
    • ⽔平分散できるとよい(冗⻑化も同じ仕組みで
    可能になる)
    • クライアントが分散しているノードを知らないと
    いけないのは不便
    • クライアントのいるネットワークに⾯したリバ
    ースプロキシをロードバランサとする
    +!"+!"+
    | LB | ( reverse proxy )
    +!"+!"+
    |
    +!"+!"+
    | APP |
    +!"+!"+
    ※ LB(Load Balancer = 負荷分散装置)
    !"

    View full-size slide

  28. http ロードバランサーをNginxで実装する
    http {
    upstream backend {
    server main.example.hatena.ne.jp weight=5;
    server sub1.example.hatena.ne.jp;
    server sub2.example.hatena.ne.jp;
    server backup.example.hatena.ne.jp backup;
    }
    access_log /var/log/nginx/access.log; !" ΞΫηεϩάΛอଘ͢Δػೳ΋࣋ͨͤΔ
    server {
    listen 80
    listen 443 ssl; !" SSLΛฏจʹ΄Ͳ͘໾ׂΛ࣋ͨͤΔ
    !!#
    location / {
    proxy_pass http:!"backend;
    }
    }
    }
    !"

    View full-size slide

  29. いろいろなロードバランシング
    • 設定で重み付けを⾏う
    • ラウンドロビン(順番に回していく)
    • コネクション数が少ないサーバーに対して振っていく
    • 処理時間が短い(⾼速な)サーバーに多く振っていく
    • なんらかの計測値に基づきリソースの余裕があるサーバに振る
    • IPアドレスやCookieの値に基づいて決まったサーバーに割り振るs
    ! アプリケーションレイヤーのキャッシュをうまく効かせたいなどの理由で、特定のクライアントの接続を特定の
    ノードに偏らせたい場合があります。ノードの増減があった場合に対応する Consistent Hashing などのアルゴリ
    ズムが使われます。
    !"

    View full-size slide

  30. ロードバランサーもロードバランス
    したい
    !"

    View full-size slide

  31. keepalived と LVS のアクティブ‧スタンバ

    • IPレベルで冗⻑構成を取れる
    • VRRPでアクティブとスタンバイのサーバーが
    お互いに通信を⾏う
    • アクティブなサーバーがダウンするとスタン
    バイサーバーがアクティブとなる
    • DNSラウンドロビンと組み合わせることで冗
    ⻑化と同時に⽔平分散を構成できる
    • マルチキャストが必要であるためAWSのVPC
    で使えない
    ┌────────────────┐
    │ │
    ┌───►│ Active Server │
    │ │ │
    │ └────────────────┘
    ┌────────────────┐ │ ▲
    │ │ VIP │ │
    │ Client ├───────┘ │ VRRP
    │ │ │
    └────────────────┘ ▼
    ┌────────────────┐
    │ │
    │ Standby Server │
    │ │
    └────────────────┘
    !"

    View full-size slide

  32. DNS ラウンドロビン
    • DNS で 複数の IP アドレスの 1 つを返

    • 低コストに導⼊できる
    • クライアントのDNSキャッシュの影響
    を受ける
    • ダウンしたノードに対してもリクエス
    トが送られるY
    • DNS名が使えない場⾯では使えない
    Q1: server.example.com
    A1: 192.0.2.1
    ┌─────────────────┐ ┌────────────────┐ ┌────────────────┐
    │ │ │ │ │ │
    │ DNS Server │◄────────────►│ Client A ├────────►│ Server X │
    │ │ │ │ │ 192.0.2.1 │
    │ │ │ │ ┌────►│ │
    └─────────────────┘ └────────────────┘ │ └────────────────┘
    ▲ ▲ ▲ │
    │ │ │ ┌────────────────┐ │ ┌────────────────┐
    │ │ │ │ │ │ │ │
    │ │ │ │ Client B ├───┼────►│ Server Y │
    │ │ └────────────────►│ │ │ │ 192.0.2.2 │
    │ │ Q2: server.example.com│ │ │ │ │
    │ │ A2: 192.0.2.2 └────────────────┘ │ └────────────────┘
    │ │ │
    │ │ ┌────────────────┐ │ ┌────────────────┐
    │ │ │ │ │ │ │
    │ │ │ Client C ├───┼────►│ Server Z │
    │ └──────────────────────►│ │ │ │ 192.0.2.3 │
    │ Q3: server.example.com│ │ │ │ │
    │ A3: 192.0.2.3 └────────────────┘ │ └────────────────┘
    │ │
    │ ┌────────────────┐ │
    │ │ │ │
    │ │ Client D │ │
    └────────────────────────────►│ ├───┘
    Q4: server.example.com│ │
    A4: 192.0.2.1 └────────────────┘
    ! AWSのRoute,-など、ヘルスチェック機能を持つDNSサービスを利⽤することで回避できる場合があります
    !"

    View full-size slide

  33. クラウドサービスのロードバランサー
    • AWSを利⽤している場合、ALB/NLBを利⽤することで冗⻑化されたロードバランサーを利⽤でき

    • リバースプロキシで実装されがちな以下の機能を備えている
    • TLS接続の終端
    • アクセスログの記録
    • URLパターンによる分岐
    • 固定レスポンスやリダイレクトルール
    • 認証システムとの連携
    • IPアドレスなどによる接続制御
    !!

    View full-size slide

  34. コンテンツ配信
    !"

    View full-size slide

  35. CDN(Contents Delivery Network)
    配信を効率的に⾏う
    本体となるWebアプリケーション
    (オリジン)とユーザーの間の経路
    や中間のキャッシュなどを最適化し
    て効率の良い配信を実現する
    DDoS攻撃に対する防御も期待できる
    アウトバウンドネットワーク費⽤を
    削減できる場合もある
    +-----+
    | CDN |
    +!"+!"+
    |
    !"

    View full-size slide

  36. CDNサービス
    • Amazon CloudFront
    • Google Cloud CDN
    • Azure Content Delivery Network
    • さくらウェブアクセラレータ
    • Akamai
    • Fastly
    • Cloudflare
    !"

    View full-size slide

  37. データベースなど
    !"

    View full-size slide

  38. 永続化層
    • メモリ上のデータをプロセスが終了しても消えないようにする
    • データベースやアップロードされたファイル、レポート、セッション情報など多岐
    にわたる
    +--------+
    +!"+!"+ +!"+!"+
    | DB | | KVS |
    +-----+ +-----+
    • 参照系と更新系で特性が⼤きく異なる
    • 可⽤性、冗⻑性に加えて⼀貫性、整合
    性や堅牢性が主要な話題になる
    • 更新処理を受け付けるノードはSPOF
    であることを許容することがある
    !"

    View full-size slide

  39. レプリケーションとシャーディング
    説明
    レプリケーション 全く同じ内容のデータセットを構築して負荷分散する
    参照系は読み取り専⽤のレプリカを増やせばよいため負荷
    分散しやすいが、更新系の負荷が⾼まると⼯夫が必要になる
    特定のテーブルのみを持つレプリカを構成する場合もある
    が、レプリカが同じデータを持つ場合、冗⻑化やバックアッ
    プとしても利⽤できる
    シャーディング
    (⽔平パーティショニング)
    データをなんらかのルールで分割し、異なるノードに保存
    する。たとえば奇数IDならDBê、偶数IDならDBíというよう
    に分割する
    更新が多い場合でも負荷分散しやすいが、アプリケーション
    でロジックを持つことになる場合がある
    冗⻑化は複数ノードを考慮する必要がある
    !"

    View full-size slide


  40. あるECプラットフォームのシステムのパフォーマンスを測定した
    ら、上位2%の店舗が全体の30%の商品数を持ち、全体の50%のト
    ラフィックを受けていた。当該店舗は更新頻度も⾼く、平均の3倍
    の頻度で価格や画像などの商品データを変更していた。
    !"

    View full-size slide

  41. 局所性とホットスポット
    永続化層の負荷対策では偏りが顕著になることがあります
    アプリケーションの変更やサービスの成⻑により変化するため、計測
    しましょう
    • 特定コンテンツにアクセスが⾮常に多い
    • 更新されたばかりのデータは圧倒的にアクセスされることが多く、1
    ヶ⽉以上前のデータはほとんどアクセスされない
    • 時間、⽇付、特定の曜⽇、季節などで利⽤のされ⽅が変わる
    !"

    View full-size slide

  42. 構成例
    • Writerはスタンバイ系に対して同期的レ
    プリケーションを⾏う
    • Readerは複数ノードを⽤意し⽔平分散で
    きるようにする
    • Writerのパフォーマンスを劣化させない
    ため、Readerへは⾮同期レプリケーショ
    ンを⾏う
    • Readerは結果整合モデルとなる
    • 強整合の参照をしたい場合はWriterで
    参照を⾏う
    +-----------+ Replication +-----------+
    | | (sync) | |
    | Writer | | Writer |
    | (Active) +--------------> (Stand By)|
    | | | |
    +-----+-----+ +-----------+
    v
    Replication (async)
    +
    +-----------+-+------------+
    | | |
    +!!"v----+ +----v!!"+ +----v!!"+
    | | | | | |
    | Reader | | Reader | | Reader |
    | | | | | |
    +--------+ +--------+ +--------+
    • Writer(Active)に問題が起こった場合、
    Writer(Stand By)をActiveに昇格する
    • 短時間のダウンタイムは許容する
    !"

    View full-size slide

  43. 可能ならマネージドサービスを利⽤
    する
    !"

    View full-size slide

  44. 強整合性(即時整合性)と結果整合性
    この例では単⼀のクライアントのみ
    が読み書きを⾏なっているとします
    def read():
    with Db.connect() as db:
    # σʔλϕʔε͔ΒಡΈग़ͨ͠஋Λฦ͢
    return db.read("key1")
    def write_and_read(value):
    with Db.connect() as db:
    # σʔλϕʔε΁ॻ͖ࠐΈΛߦ͏
    db.write("key1", value)
    return read()
    強整合
    • write_and_read() の戻り値は
    パラメータに渡した値と必ず⼀
    致する
    • read() の戻り値は最後に呼び出
    した write_and_read() のパ
    ラメータと必ず⼀致する
    !!

    View full-size slide

  45. 強整合性(即時整合性)と結果整合性
    この例では単⼀のクライアントのみ
    が読み書きを⾏なっているとします
    def read():
    with Db.connect() as db:
    # σʔλϕʔε͔ΒಡΈग़ͨ͠஋Λฦ͢
    return db.read("key1")
    def write_and_read(value):
    with Db.connect() as db:
    # σʔλϕʔε΁ॻ͖ࠐΈΛߦ͏
    db.write("key1", value)
    return read()
    結果整合
    • write_and_read() の戻り値は
    引数に渡した値と⼀致しないか
    もしれない
    • read() の結果は最後に呼び出し
    た write_and_read() の引数
    に収束する
    !"

    View full-size slide

  46. アプリケーションでの対応が必要
    • 読み取り先が強整合でない場合、問い合わせてよい場合とまずい
    場合がある
    • ショッピングカートに⼊れる際の在庫と商品数の引き当てな
    どは常に最新の値が欲しい
    • 書き込みや変更を⾏った直後の読み込みは最新であってほしい
    • ランキングや「いいね」を押した⾃分以外のユーザーの数は最
    新でなくともよい
    !"

    View full-size slide

  47. 注意: 誤操作への対策
    冗⻑化をしても誤操作への対策にはなりません
    バックアップとリストア⽅法を整備することになりますが、⼀筋縄ではいきません
    • 遅延レプリケーションや差分バックアップなどを活⽤する
    • ⼤きなデータベースのフルバックアップは時間がかかります
    • SKであればバージョニングが利⽤できる
    • リストア時の⼀貫性の保証はシステム全体の課題
    • 複数のデータストアの内容を整合するバージョンに戻すことや、リストアを⾏なってい
    る最中に新規の書き込みを抑⽌するなど
    !"

    View full-size slide

  48. おさらい
    !"

    View full-size slide

  49. ⾼可⽤への道
    • 冗⻑化をして故障や障害に備える
    • 負荷分散を⾏い⾼負荷に耐えられるようにする
    • それがやりやすいようにコンポーネントを分割する
    • ファイル配信はCDNに寄せられるといい
    • アプリケーションは横に並べられるようにしよう
    • 永続化層は読み書きのワークロードの違いがある
    • なるべくクラウドの提供するサービスを利⽤する
    !"

    View full-size slide

  50. 伝統的な構成
    取り上げなかったポイント
    • セキュリティやガバナンス
    • ログ転送や分析システム
    • ビルドシステムやリポジトリ
    • 監視
    +-----+
    | CDN |
    +!"+!"+
    |
    +!"+!"+
    | LB | ( reverse proxy )
    +!"+!"+
    |
    +!"+!"+
    | APP |
    +!"+!"+
    +--------+
    +!"+!"+ +!"+!"+
    | DB | | KVS |
    +-----+ +-----+
    !"

    View full-size slide

  51. 「アプリケーションは横に並べられ
    るようにしよう」
    !"

    View full-size slide

  52. アプリケーションを横に並べるために
    アプリケーションをスケールアウトするには以下の⼯程が必要
    • 現在利⽤されているバージョンのアプリケーションを取得
    • リソースを確保して
    • アプリケーションをデプロイし
    • コンテナ技術が⼀般化してここは⾮常に安定するようになった
    • ロードバランサーに追加する
    !"

    View full-size slide

  53. 「現在利⽤されているバージョン」を⾒つけ

    現在利⽤されているバージョンが...
    • 統⼀されている
    • システム的に特定できる
    • 利⽤可能である
    !
    < 「利⽤可能である」当たり前のようですが、しばらくデプロイされていないシステムで
    は新しくセットアップしようとするとうまくいかない、ということは往々にしてあります
    !"

    View full-size slide

  54. アプリケーションのデリバリーをシ
    ステム化したい
    !"

    View full-size slide

  55. 継続的デプロイメント
    継続的デプロイ(英語: Continuous deployment; CD)は⾃動化された
    デプロイによって⾼い頻度で最新のソフトウェア機能を提供し続けるソ
    フトウェア開発⼿法‧運⽤⼿法である。すなわち、⾃動化により、開発
    された最新のソフトウェアをユーザーが常に利⽤可能にしておく⼿法で
    ある。開発されたソフトウェアを絶え間なく、継続的にデプロイし続け
    ることから継続的デプロイと呼ばれる。
    開発の終了と運⽤の開始を継ぎ⽬なく結ぶ⽅法であり、開発と運⽤の境
    界を無くすDevOpsの⼀種である。
    --https://ja.wikipedia.org/wiki/継続的デプロイ
    !!

    View full-size slide

  56. 開発運⽤全体と分離できない
    信頼性、⽣産性、コスト、モニタリング
    +--------------+
    | |
    | Reliability +---------------+
    | | |
    +------+-------+ +-----+------+
    | | |
    | | Cost |
    | | |
    +------+-------+ +-----+------+
    | | |
    | Productivity +---------------+
    | |
    +--------------+
    ( ᯣ _ ᯣ ) !!" Monitoring
    信頼性を作り込もうとすると結局...
    • アプリケーションに対する制約や、デプロ
    イの仕組みを設計することになる
    • インフラの構成は開発するための環境に影
    響を与える
    • インフラの作りが開発のボトルネックに
    なっていないか? 認知負荷や⼿元環境
    構築がコスト⾼くないか?
    • コストはシステムの⽣み出す価値と天秤に
    かける必要がある
    !"

    View full-size slide

  57. ⽣産性(Productivity)
    悪化や改善を気にするなら指標が必要(デマルコの⾔葉を思いだそう)
    • Four Keys
    • DevOps Research and Assesment (DORA) チームが実施した研究で、
    開発チームのパフォーマンスを表す指標として⽰されたもの
    • 書籍「LeanとDevOpsの科学」などに詳しい
    • 変更リードタイム、デプロイ回数、変更障害率、サービス復元時間
    • Google が Four Keys と呼んでる
    !"

    View full-size slide

  58. データがないと評価できない
    • デプロイ回数を取得するには?
    • 変更リードタイムはどう測定する?
    • インフラ費⽤はどのように変化しているか? それは妥当か?
    • 変更障害率、サービス復元時間はどう計算する?
    データを取るためには形式化、システム化する必要がある。たとえばサーバー
    にログインしてコードを書き換える、というような⾏為は禁⽌しなければいけ
    ない。障害が起こったらそれを記録しなければいけない。コストについてはビ
    ジネス担当と認識を揃えていこう。
    !"

    View full-size slide

  59. ⾒落とされる「変更しやすさ」
    • 変更して壊れることは測定できる
    • 変更されなければ壊れない
    • 壊れていないことは何かのシグナルとして扱えるか?
    !"

    View full-size slide

  60. どんどん変更する世界に
    • 実際に変更することで変更容易性はテストされ続ける
    • ⼈的、費⽤的コストの変化は効果とともに透明にしたい
    • 壊れるときの影響範囲は局所化されたい
    • 多数のコンポーネントを頻繁に調整したい
    • 変化するので監視するポイントを予⾒‧固定できない
    !"

    View full-size slide

  61. インフラを取り巻く現代のプラクティス
    • SRE
    • BizDevOps
    • マイクロサービスアーキテクチャ
    • コンテナ技術
    • IaCとオーケストレーション
    • オブザーバビリティ
    !"

    View full-size slide

  62. おわりに


    私はWebサービスを開発運⽤するときのインフラについて雰
    囲気をつかみました
    • [ ] 私はいざとなったらインフラと向き合う覚悟を完了しました
    !"

    View full-size slide