はてなインターンシップ2024 インフラ講義資料

by Hatena

Embed

Start on current slide

Slide 1

Slide 1 text

ߴՄ༻ੑΛҙࣝͨ͠WEBΠϯϑϥ IBUFOBJOUFSO !

Slide 2

Slide 2 text

͸͡Ίʹ IBUFOBJOUFSO !

Slide 3

Slide 3 text

• ⾃⼰紹介 • この講義について IBUFOBJOUFSO !

Slide 4

Slide 4 text

ࣗݾ঺հ • はてなid: k*s*eee • 株式会社はてな • 組織基盤‧開発本部プラットフォーム部 • システムプラットフォームチーム SRE • 所属オフィス • 東京オフィス（ほぼフルリモート勤務） • 好きなAWSサービス • EC_ • 趣味 • ゲーム、映画、ソロキャンプ IBUFOBJOUFSO !

Slide 5

Slide 5 text

͜ͷߨٛͰ࿩͢͜ͱ • インフラの概観 • RASIS • ⾼可⽤に向けたアプローチ • 可⽤性の低いインフラ構成の例 • ⾼可⽤を獲得したインフラの例 • モニタリングとアラート IBUFOBJOUFSO !

Slide 6

Slide 6 text

Πϯϑϥͷ֓؍ IBUFOBJOUFSO !

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

WEBαʔϏεͷΠϯϑϥ 'WEB System' - ( 'Application' + 'Data' ) = 'Infra' • アプリケーションを動かすための⼟台となるもの IBUFOBJOUFSO !

Slide 9

Slide 9 text

Πϯϑϥͷओͳߏ੒ཁૉ サーバ CPU,メモリなどストレージ HDD, SSD, エフェメラルストレージなどネットワーク NIC,VPC などソフトウェア各種OS、各種ミドルウェアなど IBUFOBJOUFSO !

Slide 10

Slide 10 text

RASIS RASIS（レイシス、ラシスと読む）は機器、シスムやコンピュータ等の総合的な評価指数コンピュータシステムに関する評価指標の頭⽂字を並べたもの特に最初の3つをRASという • Reliability（信頼性） • Availability（可⽤性） • Serviceability（保守性） • Integrity（完全性） • Security（機密性） IBUFOBJOUFSO !"

Slide 11

Slide 11 text

Reliabilityʢ৴པੑʣ • システムが故障やエラーなく動作し続ける能⼒。 • 例: サーバやネットワーク機器が⻑期間安定して動作すること。 • 代表的な評価指数: • 平均故障間隔（Mean Time Between Failures、MTBF） IBUFOBJOUFSO !!

Slide 12

Slide 12 text

AvailabilityʢՄ༻ੑʣ • システムが利⽤可能な時間の割合。 • 例: サーバの稼働率、ウェブサイトがユーザーに常時アクセス可能であること。 • 代表的な評価指数 • 稼働率 =（総稼動時間 − 累計障害時間）/ 総稼動時間 * 100 この講義では可⽤性に注⽬します IBUFOBJOUFSO !"

Slide 13

Slide 13 text

Serviceabilityʢอकੑʣ • システムの修理やメンテナンスの容易さ。 • 例: ハードウェアの修理時間の短縮、ソフトウェアのアップデートの容易さ。 • 代表的な評価指数: • 平均修理時間（Mean Time To Repair、MTTR） IBUFOBJOUFSO !"

Slide 14

Slide 14 text

Integrityʢ׬શੑʣ • データやシステムの正確性と⼀貫性が保たれていること。 • 例: データの改ざん防⽌、トランザクションの⼀貫性の確保。 IBUFOBJOUFSO !"

Slide 15

Slide 15 text

Securityʢػີੑʣ • システムやデータが不正アクセスや攻撃から保護されていること。 • 例: データ暗号化、認証と認可の仕組み。 IBUFOBJOUFSO !"

Slide 16

Slide 16 text

Մ༻ੑ: Քಇ཰ܭࢉͷྫ 稼働率＝（総稼動時間−累計障害時間）/ 総稼動時間 * 100 γεςϜͷ30೔ؒͰͷՔಇ཰Λܭࢉ͢Δྫ • 総稼動時間: 30day = /0h * 34day = 5/4h • 累計障害時間: 10h • 稼働率: (5/4h - ?4h) / 5/4h * ?44 = BC.E?% IBUFOBJOUFSO !"

Slide 17

Slide 17 text

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 (

Slide 18

Slide 18 text

ࢀߟ: ެ։͞Ε͍ͯΔSLAͷྫ • AWS • https://aws.amazon.com/jp/legal/service-level-agreements/ • Google Workspace • https://workspace.google.com/terms/sla/ • さくらクラウド • https://cloud.sakura.ad.jp/sla/ IBUFOBJOUFSO !"

Slide 19

Slide 19 text

Մ༻ੑ͕ߴ͍ͱԿ͕خ͍͔͠ • ユーザの体験が向上する • ビジネスの継続性が向上する • ユーザ、ビジネスサイドからの信頼性が向上する IBUFOBJOUFSO !"

Slide 20

Slide 20 text

ߴՄ༻ʹ޲͚ͨΞϓϩʔν IBUFOBJOUFSO !"

Slide 21

Slide 21 text

খن໛ͳαʔϏεͷΠϯϑϥߏ੒ͷྫ • 新しいWEBサービスを開発したときのインフラ構成の例です • WEBシステムの機能を1台のサーバに全て詰め込むモノリシックアーキテクチャ（Monolithic Architecture）でサービスを開始しました IBUFOBJOUFSO !"

Slide 22

Slide 22 text

ϞϊϦγοΫΞʔΩςΫνϟͰͷ՝୊ IBUFOBJOUFSO !!

Slide 23

Slide 23 text

ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 1/2 課題説明単⼀障害点⼀部の障害がシステム全体を停⽌させるリスクスケーラビリティの制限システム全体のスケールアップが必要で、リソース効率が悪いチーム開発の⾮効率複数のチームでの同時作業が困難デプロイの難しさ⼩さな変更でも全体の再デプロイが必要で、ダウンタイムが発⽣ IBUFOBJOUFSO !"

Slide 24

Slide 24 text

ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 2/2 課題説明開発の複雑性コードが⼤規模化し、管理や変更が困難保守性の低下コードの品質が低下しやすく、リファクタリングが困難技術スタックの制限全体が同じ技術に依存し、最適な技術選択が難しい起動時間の増加アプリケーションが⼤きくなるとシステム起動までの時間が⻑くなる IBUFOBJOUFSO !"

Slide 25

Slide 25 text

Մ༻ੑΛ޲্ͤ͞ΔΞϓϩʔν IBUFOBJOUFSO !"

Slide 26

Slide 26 text

ຊ೔͓࿩͢ΔߴՄ༻ʹ޲͚ͨΞϓϩʔν アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性) S (セキュリティ) 分散アーキテクチャの導⼊ ✓ ✓ ✓ 冗⻑化、⽔平スケーリングの導⼊ ✓ ✓ CDNの導⼊ ✓ ✓ ✓ モニタリングとアラート ✓ IBUFOBJOUFSO !"

Slide 27

Slide 27 text

ͦͷଞͷΞϓϩʔνͷྫ アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性) S (セキュリティ) テスト/デプロイ⾃動化 (CI/CD) ✓ 運⽤⼿順の⽂書化 ✓ バックアップ戦略の強化 ✓ ✓ トランザクション管理の強化 ✓ データ整合性チェックの導⼊ ✓ アクセス制御と認証の強化 ✓ 暗号化の導⼊ ✓ IBUFOBJOUFSO !"

Slide 28

Slide 28 text

෼ࢄΞʔΩςΫνϟʢDistributed Architectureʣͷಋೖ IBUFOBJOUFSO !"

Slide 29

Slide 29 text

ϞϊϦγοΫΞʔΩςΫνϟ͔Β෼ࢄΞʔΩςΫνϟ΁มߋ͢Δ IBUFOBJOUFSO !"

Slide 30

Slide 30 text

෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 1/3 メリット説明スケーラビリティ個別のコンポーネントやサービスを独⽴してスケールアップ/ダウンが可能柔軟性新技術の導⼊や既存コンポーネントの更新が容易耐障害性⼀部のコンポーネントの障害が全体に波及しにくい構造開発の効率化⼩規模なチームが独⽴して開発可能、並⾏開発が容易技術の多様性各コンポーネントに最適な技術スタックを選択可能 IBUFOBJOUFSO !"

Slide 31

Slide 31 text

෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 2/3 メリット説明継続的デプロイ個別のコンポーネントを独⽴してデプロイ可能保守性⼩規模なコンポーネントは理解や保守が容易チーム開発の効率化個別のコンポーネントごとに開発チームを分けるといった事が可能になり開発効率が上がるリソース最適化必要なコンポーネントのみをスケールアップし、リソースを効率的に利⽤サービスの再利⽤共通のサービスを複数のアプリケーションで再利⽤可能 IBUFOBJOUFSO !"

Slide 32

Slide 32 text

෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 3/3 メリット説明パフォーマンス向上負荷分散やキャッシュの効果的な利⽤が可能セキュリティの強化コンポーネント間の境界でのセキュリティ制御が可能、影響範囲の限定化アクセス制御の粒度各サービスやコンポーネントに対して細かなアクセス制御が可能セキュリティ更新の容易さ個別のコンポーネントに対して迅速にセキュリティパッチを適⽤可能 IBUFOBJOUFSO !"

Slide 33

Slide 33 text

৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 1/2 課題説明複雑性の増加システム全体の設計‧管理が複雑化し、運⽤の難易度が上がる通信オーバーヘッドコンポーネント間の通信が増加し、レイテンシやネットワーク負荷が増⼤データの整合性維持分散されたデータの⼀貫性を保つことが難しくなるトランザクション管理複数のサービスにまたがるトランザクションの管理が複雑になるテストの複雑化統合テストや全体的なシステムテストが難しくなる開発‧運⽤コストの増加初期の開発コストや継続的な運⽤コストが増加する可能性がある IBUFOBJOUFSO !!

Slide 34

Slide 34 text

৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 2/2 課題説明スキル要件の変化開発者や運⽤チームに新しいスキルセットが要求されるモニタリングの複雑化分散されたシステムの監視と問題の特定が難しくなるセキュリティの複雑化攻撃対象⾯が増加し、セキュリティ管理が複雑になるネットワーク依存性ネットワークの信頼性と性能がシステム全体に⼤きく影響するバージョン管理の複雑化異なるサービス間の互換性維持が難しくなるデバッグの困難さ問題の根本原因の特定と修正が複雑になる IBUFOBJOUFSO !"

Slide 35

Slide 35 text

৑௕ԽɺਫฏεέʔϦϯάͷಋೖ IBUFOBJOUFSO !"

Slide 36

Slide 36 text

3૚ߏ଄ͷ֤૚Λ৑௕Խͯ͠Մ༻ੑΛߴΊΔ 冗⻑化と合わせて⽔平スケーリングも導⼊する事で可⽤性と信頼性が⼤きく改善される • DB層の冗⻑化、⽔平スケーリング • アプリ層の冗⻑化、⽔平スケーリング • WEBサーバ層の冗⻑化、⽔平スケーリング IBUFOBJOUFSO !"

Slide 37

Slide 37 text

DB૚ IBUFOBJOUFSO !"

Slide 38

Slide 38 text

MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 1/2 ⼿順説明 1. マスター‧スレーブ構成 - 1台のマスターDBと複数のスレーブDBを設置 - マスターDBは書き込み/読み取り、スレーブDBは読み取り専⽤ 2. レプリケーションの設定 - マスターからスレーブへのデータ複製を設定 - ⾮同期レプリケーションが⼀般的 3. 負荷分散 - アプリケーションの読み取りクエリをスレーブDBに分散 - 書き込みはマスターDBで集中管理 4. フェイルオーバーの準備 - マスター障害時にスレーブを昇格させる仕組みを⽤意 - ⾃動/⼿動切り替えの選択 IBUFOBJOUFSO !"

Slide 39

Slide 39 text

MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 2/2 ⼿順説明 5. 監視とアラート - レプリケーション状態の常時監視 - 遅延や障害の検知とアラート設定 6. バックアップ戦略 - 定期的なフルバックアップとバイナリログの保存 - ポイントインタイムリカバリの準備 7. 接続管理 - プロキシソフトウェア（例：ProxySQL）の導⼊検討 - アプリケーションからの接続の抽象化 8. ⽔平スケーリング - 読み取り専⽤のレプリカを増設し負荷分散によるパフォーマンス改善と可⽤性向上 IBUFOBJOUFSO !"

Slide 40

Slide 40 text

ࢀߟ: ϚωʔδυαʔϏεΛ׆༻͢Δ • クラウドで利⽤するDBにおいては、マネージドサービスを活⽤すると冗⻑化機能を簡単に利⽤する事ができる場合が多い • クラウドベンダーの提供しているマネージドサービスを積極的に活⽤してみると良い IBUFOBJOUFSO !"

Slide 41

Slide 41 text

ΞϓϦ૚ IBUFOBJOUFSO !"

Slide 42

Slide 42 text

アプリケーション層の冗⻑化の概要 1/2 ⼿順説明 1. 複数インスタンスの作成同⼀構成のアプリケーションサーバを複数の異なるサーバーまたはコンテナで稼働 2. ロードバランサーの導⼊ LBでトラフィックを複数のアプリケーションインスタンスに分散 3. セッション管理セッション情報を外部ストレージ（例： Redis）で⼀元管理 4. キャッシュの共有アプリケーションキャッシュを外部サービス（例：Memcached）で共有 IBUFOBJOUFSO !"

Slide 43

Slide 43 text

アプリケーション層の冗⻑化の概要 2/2 ⼿順説明 5. 設定の⼀元管理設定情報を外部サービス（例：etcd, Consul）で管理し、動的に更新 6. ヘルスチェックの実装各インスタンスの状態を定期的に確認し、問題のあるインスタンスを⾃動的に切り離し 7. ⾃動⽔平スケーリングの設定負荷に応じて⾃動的にインスタンス数を増減させる 8. ログの集中管理各インスタンスのログを中央のログサーバーに集約 IBUFOBJOUFSO !"

Slide 44

Slide 44 text

WEB૚ IBUFOBJOUFSO !!

Slide 45

Slide 45 text

WEBサーバ層の冗⻑化の概要 1/2 ⼿順説明 1. 複数のWEBサーバ構築同⼀構成のWEBサーバを複数台⽤意 2. ロードバランサーの導⼊ LBでトラフィックを複数のWEBサーバに分散 3. セッション管理セッション情報を共有ストレージで管理（必要な場合） 4. 静的コンテンツの配信最適化 CDNの導⼊や共有ストレージの利⽤ IBUFOBJOUFSO !"

Slide 46

Slide 46 text

WEBサーバ層の冗⻑化の概要 2/2 ⼿順説明 %. SSL/TLS終端の設定ロードバランサーでSSL/TLS終端を⾏う 6. ヘルスチェックの実装各インスタンスの状態を定期的に確認し、問題のあるインスタンスを⾃動的に切り離し 7. ⾃動⽔平スケーリングの設定負荷に応じてWEBサーバ数を⾃動調整 8. ログの集中管理各WEBサーバのログを中央で管理 IBUFOBJOUFSO !"

Slide 47

Slide 47 text

ࢀߟ: DNSϥ΢ϯυϩϏϯ • ドメイン名に複数のIPアドレスを割り当て、クライアントのDNSクエリに対して順番に異なるIPを返す • トラフィックを複数のサーバに分散させる • 特別な装置が不要でコスト効率が良い IBUFOBJOUFSO !"

Slide 48

Slide 48 text

DNSϥ΢ϯυϩϏϯͷ໰୊఺ • DNSキャッシュの影響で負荷が均等に分散されない場合がある • 故障したサーバのアドレスが返される可能性があり、可⽤性が低下する IBUFOBJOUFSO !"

Slide 49

Slide 49 text

CDNͷಋೖ IBUFOBJOUFSO !"

Slide 50

Slide 50 text

CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 1/2 RASIS要素 CDN導⼊による効果信頼性 (Reliability) - コンテンツ複製で冗⻑性向上 - 単⼀障害点の削減 - 分散配置でデータ損失リスク低減可⽤性 (Availability) - 分散サーバーによる⾼可⽤性 - トラフィック負荷分散 - DDoS攻撃の影響軽減保守性 (Serviceability) - 中央管理でコンテンツ更新容易 - トラフィック分析やログ管理改善 - スケーリング⾃動化 IBUFOBJOUFSO !"

Slide 51

Slide 51 text

CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 2/2 RASIS要素 CDN導⼊による効果完全性 (Integrity) - コンテンツ⼀貫性確保 - データ転送整合性チェック - 最新データ提供のキャッシュ管理セキュリティ (Security) - SSL/TLS暗号化⼀元管理 - WAF（Web Application Firewall）提供 - アクセス制御とモニタリング強化 IBUFOBJOUFSO !"

Slide 52

Slide 52 text

୅දతͳCDNϓϩόΠμʔ • Akamai • Cloudﬂare • Amazon CloudFront • Google Cloud CDN • Microsoft Azure CDN • さくらインターネットウェブアクセラレータ IBUFOBJOUFSO !"

Slide 53

Slide 53 text

ߴՄ༻Λ֫ಘͨ͠Πϯϑϥͷྫ • 分散アーキテクチャの導⼊ • 冗⻑化、⽔平スケーリングの導⼊ • CDNの導⼊ IBUFOBJOUFSO !"

Slide 54

Slide 54 text

ϞχλϦϯάͱΞϥʔτͷಋೖ IBUFOBJOUFSO !"

Slide 55

Slide 55 text

ϞχλϦϯάͱΞϥʔτͷಋೖʹΑΔRASIS΁ͷظ଴ޮՌ モニタリングとアラート導⼊による期待効果 1/2 RASIS要素期待効果信頼性 (Reliability) - 問題の早期発⾒と迅速な対応 - システム動作の継続的な監視による安定性向上可⽤性 (Availability) - ダウンタイムの最⼩化 - パフォーマンス低下の事前検知と対応保守性 (Serviceability) - トラブルシューティングの効率化 - 予防的なメンテナンスの実現 IBUFOBJOUFSO !!

Slide 56

Slide 56 text

モニタリングとアラート導⼊による期待効果 2/2 RASIS要素期待効果完全性 (Integrity) - データの整合性チェックの⾃動化 - 異常なデータ操作の検知セキュリティ (Security) - セキュリティ侵害の早期検知 - 異常なアクセスパターンの識別 IBUFOBJOUFSO !"

Slide 57

Slide 57 text

ϞχλϦϯά • システムやアプリの状態を継続観察しデータ収集 • 対象：CPU、メモリ、ディスク、ネットワーク、アプリの応答時間など • リアルタイムと履歴データの管理 • ダッシュボードで状態を可視化 IBUFOBJOUFSO !"

Slide 58

Slide 58 text

Ξϥʔτ • 閾値超過や異常検知時に通知 • 通知⽅法：メール、SMS、チャット、専⽤アプリなど • アラートレベルの設定（情報、警告、重⼤など） • エスカレーションルールの設定（対応がない場合の上位通知） IBUFOBJOUFSO !"

Slide 59

Slide 59 text

ओͳར఺ • 問題の早期発⾒と対応 • システムパフォーマンスの最適化 • ⻑期的なトレンド分析でリソース管理 • インシデント対応時間の短縮 • コンプライアンス要件対応 IBUFOBJOUFSO !"

Slide 60

Slide 60 text

࣮૷࣌ͷ஫ҙ఺ • 適切な閾値設定（誤検知や⾒逃し防⽌） • アラートの優先順位付け • モニタリングシステム⾃体の冗⻑化 • データ保持期間とストレージ管理 IBUFOBJOUFSO !"

Slide 61

Slide 61 text

ࢀߟ: Mackerel • ⾼機能な監視システムをSaaSで⼿軽に試す事ができる ؂ࢹΛҭͯΔɺMackerel • https://ja.mackerel.io/ IBUFOBJOUFSO !"

Slide 62

Slide 62 text

ࢀߟ: ΦϒβʔόϏϦςΟ この講義では取り扱いませんが、オブザーバビリティ（可観測性）の概念が近年は注⽬されています IBUFOBJOUFSO !"

Slide 63

Slide 63 text

ࢀߟ: ΦϒβʔόϏϦςΟ • 現在では管理対象のシステムが限りなく複雑化したにもかかわらず、今も多くのエンジニアリングチームが、数⼗年前に開発された初期のモニタリングツールによるデバッグ⼿法を使っています。深く隠されてつかみどころがない問題を迅速に発⾒したい場⾯に、従来のツールやデバッグ⼿法ではどう考えても対処できなくなったため、必要性に迫られてオブザーバビリティツールが誕⽣しました。 -- 書籍「オブザーバビリティ‧エンジニアリング」1章より IBUFOBJOUFSO !"

Slide 64

Slide 64 text

ࢀߟ: ϝτϦΫεɺϩάɺτϨʔεΛ͏·͘࢖͍෼͚ͯՄ؍ଌੑΛߴΊΑ͏ʂ(id:masayoshi) • https://speakerdeck.com/masayoshi/metorikusu-rogu- toresuwoumakushi-ifen-keteke-guan-ce-xing-wogao-meyou IBUFOBJOUFSO !"

Slide 65

Slide 65 text

ࢀߟ: ৴པੑ͸Ϣʔβ͕ܾΊΔ΋ͷ • 「監視が信頼性を決めるのではなく、ユーザが決めるものだ」 • 可⽤性は信頼性の主要な要素かもしれないが、イコールではない -- SREサイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本からの引⽤ IBUFOBJOUFSO !"

Slide 66

Slide 66 text

ࢀߟ: SRE(Site Reliability Engineering)ʹ͍ͭͯ • サイト‧リライアビリティ‧エンジニアリング（英：Site Reliability Engineering、略： SRE）は、Google社が提唱、実践しているシステム管理とサービス運⽤の⽅法論である。サイト信頼性エンジニアリングと訳される場合もある。また、サイトリライアビリティエンジニアリングを担当するエンジニアをサイトリライアビリティエンジニア（SRE）と呼ぶ。 • SREは、主に⾃動化、モニタリング、インシデント管理、キャパシティプランニング、パフォーマンス最適化など信頼性向上に向けた改善を継続的に⾏い、速度と信頼性のバランスを取ることに注⼒します。 • システムが常に利⽤可能であるだけでなく、期待通りに機能し、ユーザーの信頼に応えられるよう努め、複雑化するインフラを効果的に運⽤し、ビジネスの成功を技術⾯からサポートします。 IBUFOBJOUFSO !!

Slide 67

Slide 67 text

Google - Site Reliability Engineering • https://sre.google/ Hatena Developer Blogɹ͸ͯͳͷαΠτ৴པੑΤϯδχΞϦϯάʢSREʣ • https://developer.hatenastaﬀ.com/archive/category/SRE IBUFOBJOUFSO !"

Slide 68

Slide 68 text

·ͱΊ • インフラの概観 • RASIS • ⾼可⽤に向けたアプローチ • サービス初期のインフラ • ⾼可⽤を獲得したインフラの例 • モニタリングとアラートについてお話しました IBUFOBJOUFSO !"