はてなサマーインターンシップ2025 クラウドと運用講義資料

by Hatena

Slide 1

Slide 1 text

Ϋϥ΢υͱӡ༻ IBUFOBJOUFSO !

Slide 2

Slide 2 text

͸͡Ίʹ IBUFOBJOUFSO !

Slide 3

Slide 3 text

͜ͷߨٛͰ࿩͢͜ͱ • クラウドコンピューティング概論 • ⾼可⽤性を実現するクラウド構成 • Infrastructure as Code と⾃動化 • モニタリングとオブザーバビリティ • DevOps∕SRE⼊⾨ • まとめ & 質疑応答 IBUFOBJOUFSO !

Slide 4

Slide 4 text

Ϋϥ΢υίϯϐϡʔςΟϯά֓࿦ IBUFOBJOUFSO !

Slide 5

Slide 5 text

IaaS/PaaS/SaaS ͷҧ͍ͱ੹೚෼ք఺ IBUFOBJOUFSO !

Slide 6

Slide 6 text

໨త • 運⽤範囲の明確化各モデルごとに「クラウド事業者が⾯倒を⾒る範囲」と「ユーザー（運⽤チーム）が⾯倒を⾒る範囲」をはっきりさせ、誤解や抜け漏れを防ぐ • コスト‧責任の最適化判断どこまで⾃前で管理すべきか（柔軟性 vs. ⼿間）の判断基準を持たせ、インフラ設計や運⽤⽅針の意思決定に役⽴てる • トラブル発⽣時の切り分け⼒強化問題が起きた際「OS の問題？ミドルウェアの問題？それともベンダー側？」と速やかに切り分けられるようにする IBUFOBJOUFSO !

Slide 7

Slide 7 text

Ϟσϧఆٛͱಛ௃ モデル提供内容（例）ユーザーの管理範囲メリット∕デメリット IaaS 仮想マシン、ストレージ、ネットワーク OS〜アプリまで全て⾃分で管理 ◯ ⾃由度↑ / △ 運⽤負荷↑ PaaS ランタイム∕ミドルウェア∕フレームワークアプリケーションとデータのみ管理 ◯ 運⽤負荷↓ / △ カスタマイズ性↓ SaaS 完全マネージドアプリケーションユーザーデータと利⽤設定のみ管理 ◯ ほぼ⼿間要らず / △ ベンダー依存度↑ IBUFOBJOUFSO !

Slide 8

Slide 8 text

੹೚෼ք఺ レイヤー IaaS PaaS SaaS アプリケーション∕設定利⽤者利⽤者事業者データ（内容‧整合性）利⽤者利⽤者利⽤者ミドルウェア∕実⾏ランタイム利⽤者事業者事業者 OS∕パッチ管理利⽤者事業者事業者仮想化基盤∕コンテナランタイム事業者事業者事業者ネットワーク（VPC等）事業者事業者事業者物理ハード∕データセンター事業者事業者事業者 IBUFOBJOUFSO !

Slide 9

Slide 9 text

ӡ༻্ͷ஫ҙ఺ IaaS：OS セキュリティパッチの定期適⽤、ログ収集設定 PaaS：ランタイムバージョンアップのタイミング確認 SaaS：データエクスポート∕バックアップ⼿順の整備 IBUFOBJOUFSO !

Slide 10

Slide 10 text

Ϋϥ΢υίϯϐϡʔςΟϯά֓؍ (·ͱΊ) • IaaS / PaaS / SaaS の責任分界 • 要件(可⽤性、性能、規制、コスト)にあったモデルのサービスを選択することが重要 • 提供モデルによってトラブル発⽣時の責任範囲が異なる IBUFOBJOUFSO !"

Slide 11

Slide 11 text

ߴՄ༻ੑΛ࣮ݱ͢ΔΫϥ΢υߏ੒ IBUFOBJOUFSO !!

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

εέʔϦϯάͷ2ͭͷํ޲ɿਨ௚ vs ਫฏ • 垂直スケーリング（Scale Up） 1台あたりのリソース（vCPU/メモリ/IOPS）を増やす例：tI.medium → mPi.Qxlarge に変更 • ⻑所：実装が容易∕単⼀ノード性能が必要なワークロードに有効 • 短所：上限がある‧⾼コスト化しやすい‧リサイズで停⽌/再起動が発⽣することがある • ⽔平スケーリング（Scale Out）同⼀役割のノードを複数台並べて負荷分散例：Webサーバを3台→10台へ、Auto ScalingやKusのHPAで⾃動増減 • ⻑所：可⽤性/耐障害性が上がる‧無停⽌で段階増設‧微粒度にコスト最適化 • 短所：アプリをステートレス化、セッション外出し、LB/ヘルスチェック等の設計が必要 IBUFOBJOUFSO !"

Slide 28

Slide 28 text

ͳͥਫฏεέʔϦϯάΛબͿέʔε͕ଟ͍ͷ ͔ • 可⽤性が上がる：1台故障でもサービス継続（SPOF回避∕フェイルオーバー容易） • 弾⼒性（エラスティシティ）：需要に合わせて⾃動で増減 → 過剰/過少プロビジョニングを抑制 • コスト効率：⼩さめのインスタンスを必要量だけ並べる⽅が単価‧無駄を抑えやすい • 上限回避：垂直⽅向の“打ち⽌め”を回避（超⼤規模でもスケール可能） • クラウド親和性：ALB/NLB＋Auto Scaling、Kubernetes HPA など標準機能で実現しやすい IBUFOBJOUFSO !"

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

DB૚ IBUFOBJOUFSO !"

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

ࢀߟ: ϚωʔδυαʔϏεΛ׆༻͢Δ • クラウドで利⽤するDBにおいては、マネージドサービスを活⽤すると冗⻑化機能を簡単に利⽤する事ができる場合が多い • クラウドベンダーの提供しているマネージドサービスを積極的に活⽤してみると良い • AWSの例 Amazon RDS（MySQL / PostgreSQL / MariaDB / SQL Server） Amazon Aurora（MySQL / PostgreSQL 互換） Amazon DynamoDB（NoSQL） Amazon DocumentDB（MongoDB互換） Amazon Neptune（グラフ） Amazon ElastiCache（Redis / Memcached） Amazon Timestream（時系列DB） Amazon Redshift（DWH） IBUFOBJOUFSO !!

Slide 34

Slide 34 text

ΞϓϦ૚ IBUFOBJOUFSO !"

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

WEB૚ IBUFOBJOUFSO !"

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

CDNͷಋೖ IBUFOBJOUFSO !"

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

ߴՄ༻ੑΛ࣮ݱ͢ΔΫϥ΢υߏ੒(·ͱΊ) • なぜ⾼可⽤が必要か • モノリシック構成の課題：単⼀障害点∕スケール制限∕デプロイ‧保守の難しさ • どう設計するか（⽅向性） • 分散アーキテクチャへの移⾏ • 各層（Web∕App∕DB）の冗⻑化と⽔平スケーリング • CDNで配信最適化と負荷分散⾼可⽤構成は要素が増えて⼿作業では維持困難。そこでInfrastructure as Codeで環境をソフトウェア化し、再現性‧変更管理‧ドリフト防⽌を実現する IBUFOBJOUFSO !"

Slide 48

Slide 48 text

Infrastructure as Code ͱࣗಈԽ IBUFOBJOUFSO !"

Slide 49

Slide 49 text

IaCʗࣗಈԽͱ͸Կ͔ʁ • 定義 • Infrastructure as Code：インフラ構成をコードで定義し、プログラムで作成‧ 管理する⼿法 • ⾃動化：コードやスクリプトでプロビジョニング→テスト→デプロイまで⼀気通貫で実⾏ • 従来との違い • ⼿動設定 ⇔ コード実⾏ • ドキュメント依存 ⇔ Git 管理 IBUFOBJOUFSO !"

Slide 50

Slide 50 text

ͳͥ“ΠϯϑϥΛιϑτ΢ΣΞԽ”͢Δͷ͔ʁ • Infrastructure as Software の意義 • コードとして扱うことで「可読性」「差分管理」「再利⽤性」を実現 • 設定⼿順やナレッジを属⼈化させず、チーム全体で共通理解を担保 • 組織にもたらす効果 • 新規メンバーでも環境構築が即可能 • レビュー∕ロールバックが容易になり運⽤リスクを低減 IBUFOBJOUFSO !"

Slide 51

Slide 51 text

એݴతઃܭͷϝϦοτ • 望ましい状態をコードで宣⾔ • 「こうあるべき」を記述し、ツールに実現を任せる • ドリフト防⽌ • 実際の状態とコードとの差分（ドリフト）を⾃動検知‧是正 • 可読性と保守性の向上 • コードを追うだけで「何がどう構成されるか」が明確 • 再利⽤性の⾼いモジュール化 • 共通パターンをモジュール化し、複数環境で簡単に再利⽤ • チーム開発との親和性 • GitOps的な運⽤に組み込みやすい IBUFOBJOUFSO !"

Slide 52

Slide 52 text

୅දతͳIaCπʔϧͱಛ௃ ツール特徴ユースケース例 Terraform 宣⾔的HCL∕マルチクラウド対応 ∕豊富なプロバイダマルチクラウド∕ハイブリッド運⽤ CloudFormation AWS専⽤YAML/JSONテンプレート ∕Drift Detection機能純AWS環境でのマネージドリソース構築 AWS CDK TypeScript/Python等で記述→CFN に変換∕⾼度抽象化ライブラリ複雑ロジックをコードで表現したい場合 Pulumi 任意⾔語（Go, Java, .NET等）で IaC∕ハイブリッド宣⾔＋命令型既存開発⾔語スキルを活かした導⼊ IBUFOBJOUFSO !"

Slide 53

Slide 53 text

CI/CD࿈ܞͱΨʔυϨʔϧ • PRベース運⽤ Git Push → ⾃動ビルド∕テスト → 差分プランの確認 → Code Review → ⾃動適⽤∕デプロイ → モニタリング • ⾃動検証 • Lint/Validate/Plan差分チェック • セキュリティスキャン（tfsec, Checkov） • Policy-as-Code（Open Policy Agent (OPA), Gatekeeper, Sentinel） IBUFOBJOUFSO !"

Slide 54

Slide 54 text

ӡ༻΁ͷམͱ͠ࠐΈϙΠϯτ • モジュール化∕共通化役割ごとにモジュールを作り、再利⽤性を⾼める • 環境分離 dev/stage/prod をコードレベルで明確に切り分け • Secrets 管理各クラウドや外部サービスが提供するシークレット管理機能（例：クラウドのマネージドSecretストア、Vaultなど）と連携して、機密情報をコード外に隔離 IBUFOBJOUFSO !"

Slide 55

Slide 55 text

Terraform αϯϓϧίʔυ # AWS EC2 Πϯελϯε࡞੒ྫ resource "aws_instance" "web" { ami = "ami-0abcdef1234567890" instance_type = "t3.micro" tags = { Name = "web-server" } } # S3 όέοτ࡞੒ྫ resource "aws_s3_bucket" "app_bucket" { bucket = "my-app-bucket" acl = "private" } IBUFOBJOUFSO !!

Slide 56

Slide 56 text

Infrastructure as Code ͱࣗಈԽ (·ͱΊ) • コード化で再現性と安定性を確保⼿動作業を排除し、いつでも同じ環境を構築可能にする • 宣⾔的設計で「望ましい状態」を⾃動維持差分検知と⾃⼰修復により運⽤負荷を削減 • CI/CD連携でフィードバックループをまわす GitOps的なワークフローと統合し、安全かつ迅速な運⽤を実現 IBUFOBJOUFSO !"

Slide 57

Slide 57 text

ϞχλϦϯάͱΦϒβʔόϏϦςΟ IBUFOBJOUFSO !"

Slide 58

Slide 58 text

ͦ΋ͦ΋ʮݟ͑ΔԽʯ͕ͳͥେࣄ͔ʁ • サービス運⽤で⼀番困るのは「気づかない不具合」 • ユーザーが「遅い」「落ちる」と感じる前に、システムの異常を早く⾒つけることが⼤切 • そのためにモニタリングとオブザーバビリティがある IBUFOBJOUFSO !"

Slide 59

Slide 59 text

ϞχλϦϯάͱ͸ • 定義：あらかじめ決めた指標（CPU、メモリ、レスポンス時間など）を監視し、異常を検知すること • ⽬的：システムの「今の状態」を知る • 例： • CPU使⽤率が90%以上になったらアラート • エラーログが1分間に100件以上出たら通知 IBUFOBJOUFSO !"

Slide 60

Slide 60 text

ϞχλϦϯάͷݶք • CPUが⾼いことは分かるけど「なぜ⾼いのか」は分からない • サーバーやコンテナが増えると「どのノードで問題が起きたのか」特定が難しい • つまり「何が起きているか」は分かるが、「なぜ起きたのか」は分からない IBUFOBJOUFSO !"

Slide 61

Slide 61 text

ΦϒβʔόϏϦςΟͱ͸ʁ • 定義：システム内部で何が起きているかを「外から集めたデータ」から理解すること • ⽬的：「なぜ遅いのか∕どこで失敗しているのか」を素早く突き⽌める • 必要な理由： • マイクロサービスやサーバレスなど複雑な構成が当たり前 • モニタリングだけでは「未知の異常」や「因果関係」が追えない IBUFOBJOUFSO !"

Slide 62

Slide 62 text

ϞχλϦϯάͱΦϒβʔόϏϦςΟͷҧ͍ 項⽬モニタリングオブザーバビリティ⽬的状態を検知する原因を理解する⼿段メトリクス∕ログ中⼼ MELT（Metrics / Events / Logs / Traces）得意「異常に気づく」「なぜ異常が起きたか掘る」例： - モニタリング → 「EC/のCPUが90%超」 - オブザーバビリティ → 「APIがボトルネック、特定クエリが遅延」 IBUFOBJOUFSO !"

Slide 63

Slide 63 text

MELTʢ4ͭͷபʣ • Metrics：リソース使⽤率やレスポンスタイムなど定量的指標 • Events：デプロイや障害などの出来事 • Logs：アプリやミドルウェアが出す詳細な履歴 • Traces：リクエストの流れを追跡（どのサービスが遅いか⼀⽬で分かる IBUFOBJOUFSO !"

Slide 64

Slide 64 text

ಘΒΕΔޮՌ • 未知の異常に気づける（例：イベントとメトリクスの相関でデプロイ由来の不具合を検知） • 原因調査が速い（トレースでボトルネック特定 → ログで詳細確認 → メトリクスで影響範囲を把握） • 複雑な環境でも俯瞰できる（マイクロサービスや外部APIの依存関係を⼀望） IBUFOBJOUFSO !"

Slide 65

Slide 65 text

MackerelͰ࣮ݱ͢ΔΦϒβʔόϏϦςΟ • Metrics：エージェントによる収集に加えて、OpenTelemetry形式（OTLP）で送信されたメトリクスも取り込み可能 • Events：デプロイや障害といった出来事をグラフアノテーションとしてメトリクスと関連づけて把握できる • Logs：ログについては対応を検討中 • Traces：OpenTelemetryからのトレースを受け取り、Vaxila(APM) でリクエスト単位の遅延やエラーを分析可能 IBUFOBJOUFSO !"

Slide 66

Slide 66 text

ඪ४ن֨ɿOpenTelemetry • OpenTelemetry は、モニタリングやオブザーバビリティのデータ収集を統⼀するためのオープンソース規格 • できること： • 1つのSDKでメトリクス∕ログ∕トレースを収集 • ベンダーに依存せず、Mackerel‧Prometheus‧Jaegerなど多様なツールにデータを送れる • ポイント： • 将来ツールを乗り換えても計測の仕組みは使い回せる • 「オブザーバビリティの共通⾔語」として世界中で利⽤が広がっている IBUFOBJOUFSO !!

Slide 67

Slide 67 text

ϞχλϦϯάͱΦϒβʔόϏϦςΟ (·ͱΊ) • モニタリング：状態を「知る」仕組み • オブザーバビリティ：原因を「理解する」仕組み • 最終的なゴールは「ユーザーに影響する前に異常を検知し、すぐに直せる体制」を作ること IBUFOBJOUFSO !"

Slide 68

Slide 68 text

DevOpsʗSREೖ໳ IBUFOBJOUFSO !"

Slide 69

Slide 69 text

DevOpsʗSREͷ֓ཁ • DevOps：開発と運⽤を統合し、迅速なデリバリーと改善を実現する⽂化 • SRE：Google発の信頼性エンジニアリング。運⽤をソフトウェア化し、速度と可⽤性を両⽴ • 位置づけ：SREはDevOpsを実現する⼿法の⼀つ • 共通点：⾃動化と可観測性で、品質とスピードを両⽴ IBUFOBJOUFSO !"

Slide 70

Slide 70 text

DevOpsʗSRE͕ॏࢹ͢Δ͜ͱ • 信頼性の設計と維持（可⽤性‧性能‧耐障害性） • 変更の安全性とスピード（IaC∕CI/CD、ロールバック） • 可観測性の確⽴（MELT基盤、ダッシュボード、アラート） • インシデント対応（オンコール→復旧→Postmortem） • コスト‧キャパシティ‧セキュリティ管理（オートスケール、コスト可視化、Policy as Code） IBUFOBJOUFSO !"

Slide 71

Slide 71 text

৴པੑΛͲ͏ଌΔ͔ʁ 「信頼性」「変更の安全性」を実際に管理するには、数値での⽬標設定が必要 • 「どのくらい成功すればよいか？」 • 「どのくらい失敗を許せるか？」 → SLI∕SLO∕エラーバジェット IBUFOBJOUFSO !"

Slide 72

Slide 72 text

SLIʗSLOʗΤϥʔόδΣοτ • SLI：品質を数値で測る指標（例：リクエスト成功率、レスポンスタイム） • SLO：その指標に対する⽬標（例：リクエスト成功率99.9%） • エラーバジェット：許容される失敗率 → 開発速度と信頼性の調整に使う単なる数値ではなく「リリースや改善の判断材料」になる IBUFOBJOUFSO !"

Slide 73

Slide 73 text

Քಇ཰ͱՄ༻ੑ 稼働率＝（総稼動時間−障害時間）/ 総稼動時間 × 100 例）30⽇間（()*h）で障害10h → !".$%% → 数字が同じでも「いつ⽌まったか」でエンドユーザーの体感品質は変わる（例：業務時間の停⽌は深夜より影響が⼤きい） IBUFOBJOUFSO !"

Slide 74

Slide 74 text

ࢀߟɿ X-Nines ͱڐ༰Մೳμ΢ϯλΠϜ Մ༻ੑ໨ඪͱμ΢ϯλΠϜ 可⽤性年間⽉間週間 ((% 3.6⽇ ../h 1..h ((.(% 2..h 34m 16m ((.((% 74m 3m 1m ((.(((% 7m /8s 8s → 「⾼可⽤性」ほどコストや仕組みが複雑になる（例：冗⻑化インフラ、マルチリージョン構成、マルチクラウド構成） IBUFOBJOUFSO !"

Slide 75

Slide 75 text

SLAͱ͸ʁ • SLA (Service Level Agreement)：サービス提供者と利⽤者の間で合意される可⽤性保証 • 例：⽉間稼働率99.9%以上を保証、下回った場合はクレジット付与 • 公開される場合もあれば、⾮公開のサービスも多い ެ։ྫ • AWS：サービス別 SLA • Google Workspace：SLA • さくらクラウド：SLA IBUFOBJOUFSO !"

Slide 76

Slide 76 text

Մ༻ੑ͕ߴ͍ͱԿ͕خ͍͔͠ • ユーザ体験向上：いつでも使える • ビジネス継続性：⽌まらない仕組み • 信頼性向上：安⼼して任せられる IBUFOBJOUFSO !"

Slide 77

Slide 77 text

Ͳ͏؂ࢹ͠ଓ͚Δ͔ʁ 可⽤性やSLAで⽬標を決めても、それを継続的に測定‧評価できなければ意味がない → ここで重要になるのがオブザーバビリティ IBUFOBJOUFSO !!

Slide 78

Slide 78 text

ΦϒβʔόϏϦςΟͷӡ༻ • 既存メトリクス∕ログの活⽤と拡充 • カスタムメトリクス追加、JSONログ化 • SLI/SLO、エラーバジェット等のダッシュボード作成、アラート設定 • Postmortemで失敗を学び改善 • 定期レビューで閾値‧項⽬を更新 IBUFOBJOUFSO !"

Slide 79

Slide 79 text

DevOpsʗSREೖ໳ (·ͱΊ) • DevOps∕SRE：⾃動化と可観測性で品質と速度を両⽴ • SLI∕SLO∕エラーバジェット：数値を使い運⽤判断を明確化 • 可⽤性とSLA：⽬標値と保証の関係を理解する • オブザーバビリティ：計測→可視化→改善のサイクルが鍵 • 技術だけでなく「信頼性を守る姿勢」が⼤切 IBUFOBJOUFSO !"

Slide 80

Slide 80 text

·ͱΊ • クラウドコンピューティング概論 • ⾼可⽤性を実現するクラウド構成 • Infrastructure as Code と⾃動化 • モニタリングとオブザーバビリティ • DevOps∕SRE⼊⾨についてお話しました IBUFOBJOUFSO !"