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

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

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

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

インフラ !

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

System - ( Application + Data ) = Infra !

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

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

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

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

信頼性、⽣産性、コストのうちで 信頼性（その中で特に可⽤性）の話 !"

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

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

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

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 (

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

複合システムの可⽤性 • シンプルなシステム構成を考える • すべてのコンポーネントの単独の可⽤性が 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%を下回ってしまった! !"

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

どうやって? !"

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

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

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

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

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

アプリケーション !"

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

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; } } } !"

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

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

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

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サービスを利⽤することで回避できる場合があります !"

クラウドサービスのロードバランサー • AWSを利⽤している場合、ALB/NLBを利⽤することで冗⻑化されたロードバランサーを利⽤でき る • リバースプロキシで実装されがちな以下の機能を備えている • TLS接続の終端 • アクセスログの記録 • URLパターンによる分岐 • 固定レスポンスやリダイレクトルール • 認証システムとの連携 • IPアドレスなどによる接続制御 !!

コンテンツ配信 !"

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

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

データベースなど !"

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

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

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

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

構成例 • 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に昇格する • 短時間のダウンタイムは許容する !"

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

強整合性（即時整合性）と結果整合性 この例では単⼀のクライアントのみ が読み書きを⾏なっているとします 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() のパ ラメータと必ず⼀致する !!

強整合性（即時整合性）と結果整合性 この例では単⼀のクライアントのみ が読み書きを⾏なっているとします 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() の引数 に収束する !"

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

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

おさらい !"

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

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

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

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

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

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

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

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

評価 !"

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

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

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

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

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

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