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

https://hatena.co.jp/recruit/intern/2025

Transcript

1. Ϋϥ΢υͱӡ༻ IBUFOBJOUFSO !
2. ͸͡Ίʹ IBUFOBJOUFSO !
3. ͜ͷߨٛͰ࿩͢͜ͱ • クラウドコンピューティング概論 • ⾼可⽤性を実現するクラウド構成 • Infrastructure as Code と⾃動化 • モニタリングとオブザーバビリティ • DevOps∕SRE⼊⾨ • まとめ & 質疑応答 IBUFOBJOUFSO !
4. Ϋϥ΢υίϯϐϡʔςΟϯά֓࿦ IBUFOBJOUFSO !
5. IaaS/PaaS/SaaS ͷҧ͍ͱ੹೚෼ք఺ IBUFOBJOUFSO !
6. ໨త • 運⽤範囲の明確化 各モデルごとに「クラウド事業者が⾯倒を⾒る範囲」と「ユーザー（運⽤チ ーム）が⾯倒を⾒る範囲」をはっきりさせ、誤解や抜け漏れを防ぐ • コスト‧責任の最適化判断 どこまで⾃前で管理すべきか（柔軟性 vs. ⼿間）の判断基準を持たせ、インフ ラ設計や運⽤⽅針の意思決定に役⽴てる • トラブル発⽣時の切り分け⼒強化 問題が起きた際「OS の問題？ ミドルウェアの問題？ それともベンダー 側？」と速やかに切り分けられるようにする IBUFOBJOUFSO !
7. Ϟσϧఆٛͱಛ௃ モデル 提供内容（例） ユーザーの管理範囲 メリット∕デメリッ ト IaaS 仮想マシン、ストレー ジ、ネットワーク OS〜アプリまで全て ⾃分で管理 ◯ ⾃由度↑ / △ 運⽤ 負荷↑ PaaS ランタイム∕ミドルウ ェア∕フレームワーク アプリケーションとデ ータのみ管理 ◯ 運⽤負荷↓ / △ カ スタマイズ性↓ SaaS 完全マネージドアプリ ケーション ユーザーデータと利⽤ 設定のみ管理 ◯ ほぼ⼿間要らず / △ ベンダー依存度↑ IBUFOBJOUFSO !
8. ੹೚෼ք఺ レイヤー IaaS PaaS SaaS アプリケーション∕設定 利⽤者 利⽤者 事業者 データ（内容‧整合性） 利⽤者 利⽤者 利⽤者 ミドルウェア∕実⾏ランタイ ム 利⽤者 事業者 事業者 OS∕パッチ管理 利⽤者 事業者 事業者 仮想化基盤∕コンテナランタ イム 事業者 事業者 事業者 ネットワーク（VPC等） 事業者 事業者 事業者 物理ハード∕データセンター 事業者 事業者 事業者 IBUFOBJOUFSO !
9. ӡ༻্ͷ஫ҙ఺ IaaS：OS セキュリティパッチの定期適⽤、ログ収集設定 PaaS：ランタイムバージョンアップのタイミング確認 SaaS：データエクスポート∕バックアップ⼿順の整備 IBUFOBJOUFSO !
10. Ϋϥ΢υίϯϐϡʔςΟϯά֓؍ (·ͱΊ) • IaaS / PaaS / SaaS の責任分界 • 要件(可⽤性、性能、規制、コスト)にあったモデルのサービス を選択することが重要 • 提供モデルによってトラブル発⽣時の責任範囲が異なる IBUFOBJOUFSO !"
11. ߴՄ༻ੑΛ࣮ݱ͢ΔΫϥ΢υߏ੒ IBUFOBJOUFSO !!
12. খن໛ͳαʔϏεͷΠϯϑϥߏ੒ͷྫ • 新しいWEBサービスを開発したときのインフラ構成の例です • Webの3層構造（プレゼンテーション層、アプリケーション層、データ層）のアーキテクチャ • 3層構造を1台のサーバに全て詰め込むモノリシックアーキテクチャ（Monolithic Architecture）でサービスを開始しました IBUFOBJOUFSO !"
13. ϞϊϦγοΫΞʔΩςΫνϟͰͷ՝୊ IBUFOBJOUFSO !"
14. ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 1/2 課題 説明 単⼀障害点 ⼀部の障害がシステム全体を停⽌させるリス ク スケーラビリティの制限 システム全体のスケールアップが必要で、リ ソース効率が悪い チーム開発の⾮効率 複数のチームでの同時作業が困難 デプロイの難しさ ⼩さな変更でも全体の再デプロイが必要で、 ダウンタイムが発⽣ IBUFOBJOUFSO !"
15. ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 2/2 課題 説明 開発の複雑性 コードが⼤規模化し、管理や変更が困難 保守性の低下 コードの品質が低下しやすく、リファクタリ ングが困難 技術スタックの制限 全体が同じ技術に依存し、最適な技術選択が 難しい 起動時間の増加 アプリケーションが⼤きくなるとシステム起 動までの時間が⻑くなる IBUFOBJOUFSO !"
16. Մ༻ੑΛ޲্ͤ͞ΔΞϓϩʔν IBUFOBJOUFSO !"
17. ߴՄ༻ʹ޲͚ͨΞϓϩʔν アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性) S (セキュリティ) 分散アーキテク チャの導⼊ ✓ ✓ ✓ 冗⻑化、⽔平ス ケーリングの導 ⼊ ✓ ✓ CDNの導⼊ ✓ ✓ ✓ モニタリングと アラート ✓ IBUFOBJOUFSO !"
18. ͦͷଞͷΞϓϩʔνͷྫ アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性) S (セキュリティ) テスト/デプロイ⾃動化 (CI/CD) ✓ 運⽤⼿順の⽂書化 ✓ バックアップ戦略の強 化 ✓ ✓ トランザクション管理 の強化 ✓ データ整合性チェック の導⼊ ✓ アクセス制御と認証の 強化 ✓ 暗号化の導⼊ ✓ IBUFOBJOUFSO !"
19. ෼ࢄΞʔΩςΫνϟʢDistributed Architectureʣͷಋೖ IBUFOBJOUFSO !"
20. ϞϊϦγοΫΞʔΩςΫνϟ͔Β෼ࢄΞʔΩςΫνϟ΁มߋ͢Δ IBUFOBJOUFSO !"
21. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 1/3 メリット 説明 スケーラビリティ 個別のコンポーネントやサービスを独⽴してスケー ルアップ/ダウンが可能 柔軟性 新技術の導⼊や既存コンポーネントの更新が容易 耐障害性 ⼀部のコンポーネントの障害が全体に波及しにくい 構造 開発の効率化 ⼩規模なチームが独⽴して開発可能、並⾏開発が容 易 技術の多様性 各コンポーネントに最適な技術スタックを選択可能 IBUFOBJOUFSO !"
22. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 2/3 メリット 説明 継続的デプロイ 個別のコンポーネントを独⽴してデプロイ可能 保守性 ⼩規模なコンポーネントは理解や保守が容易 チーム開発の効率化 個別のコンポーネントごとに開発チームを分けると いった事が可能になり開発効率が上がる リソース最適化 必要なコンポーネントのみをスケールアップし、リ ソースを効率的に利⽤ サービスの再利⽤ 共通のサービスを複数のアプリケーションで再利⽤ 可能 IBUFOBJOUFSO !!
23. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 3/3 メリット 説明 パフォーマンス向上 負荷分散やキャッシュの効果的な利⽤が可能 セキュリティの強化 コンポーネント間の境界でのセキュリティ制 御が可能、影響範囲の限定化 アクセス制御の粒度 各サービスやコンポーネントに対して細かな アクセス制御が可能 セキュリティ更新の容易さ 個別のコンポーネントに対して迅速にセキュ リティパッチを適⽤可能 IBUFOBJOUFSO !"
24. ৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 1/2 課題 説明 複雑性の増加 システム全体の設計‧管理が複雑化し、運⽤の難易度が上がる 通信オーバーヘッド コンポーネント間の通信が増加し、レイテンシやネットワーク 負荷が増⼤ データの整合性維持 分散されたデータの⼀貫性を保つことが難しくなる トランザクション管理 複数のサービスにまたがるトランザクションの管理が複雑にな る テストの複雑化 統合テストや全体的なシステムテストが難しくなる 開発‧運⽤コストの増加 初期の開発コストや継続的な運⽤コストが増加する可能性があ る IBUFOBJOUFSO !"
25. ৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 2/2 課題 説明 スキル要件の変化 開発者や運⽤チームに新しいスキルセットが要求される モニタリングの複雑化 分散されたシステムの監視と問題の特定が難しくなる セキュリティの複雑化 攻撃対象⾯が増加し、セキュリティ管理が複雑になる ネットワーク依存性 ネットワークの信頼性と性能がシステム全体に⼤きく影 響する バージョン管理の複雑化 異なるサービス間の互換性維持が難しくなる デバッグの困難さ 問題の根本原因の特定と修正が複雑になる IBUFOBJOUFSO !"
26. ৑௕ԽɺਫฏεέʔϦϯάͷಋೖ IBUFOBJOUFSO !"
27. εέʔϦϯάͷ2ͭͷํ޲ɿਨ௚ vs ਫฏ • 垂直スケーリング（Scale Up） 1台あたりのリソース（vCPU/メモリ/IOPS）を増やす 例：tI.medium → mPi.Qxlarge に変更 • ⻑所：実装が容易∕単⼀ノード性能が必要なワークロードに有効 • 短所：上限がある‧⾼コスト化しやすい‧リサイズで停⽌/再起動が発⽣することがある • ⽔平スケーリング（Scale Out） 同⼀役割のノードを複数台並べて負荷分散 例：Webサーバを3台→10台へ、Auto ScalingやKusのHPAで⾃動増減 • ⻑所：可⽤性/耐障害性が上がる‧無停⽌で段階増設‧微粒度にコスト最適化 • 短所：アプリをステートレス化、セッション外出し、LB/ヘルスチェック等の設計が必要 IBUFOBJOUFSO !"
28. ͳͥਫฏεέʔϦϯάΛબͿέʔε͕ଟ͍ͷ ͔ • 可⽤性が上がる：1台故障でもサービス継続（SPOF回避∕フェイルオーバー容易） • 弾⼒性（エラスティシティ）：需要に合わせて⾃動で増減 → 過剰/過少プロビジョニング を抑制 • コスト効率：⼩さめのインスタンスを必要量だけ並べる⽅が単価‧無駄を抑えやすい • 上限回避：垂直⽅向の“打ち⽌め”を回避（超⼤規模でもスケール可能） • クラウド親和性：ALB/NLB＋Auto Scaling、Kubernetes HPA など標準機能で実現しや すい IBUFOBJOUFSO !"
29. 3૚ߏ଄ͷ֤૚Λ৑௕Խͯ͠Մ༻ੑΛߴΊΔ 冗⻑化と合わせて⽔平スケーリングも導⼊する事で可⽤性と信頼 性が⼤きく改善される • DB層の冗⻑化、⽔平スケーリング • アプリ層の冗⻑化、⽔平スケーリング • WEBサーバ層の冗⻑化、⽔平スケーリング IBUFOBJOUFSO !"
30. DB૚ IBUFOBJOUFSO !"
31. MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 1/2 ⼿順 説明 1. プライマリ‧レプリカ構成 - 1台のプライマリDBと複数のレプリカDBを設置 - プライマリDBは書き込み/読み取り、レプリカDBは読 み取り専⽤ 2. レプリケーションの設定 - プライマリからレプリカへのデータ複製を設定 - ⾮同期レプリケーションが⼀般的 3. 負荷分散 - アプリケーションの読み取りクエリをレプリカDBに分 散 - 書き込みはプライマリDBで集中管理 4. フェイルオーバーの準備 - プライマリ障害時にレプリカを昇格させる仕組みを⽤ 意 - ⾃動/⼿動切り替えの選択 IBUFOBJOUFSO !"
32. MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 2/2 ⼿順 説明 5. 監視とアラート - レプリケーション状態の常時監視 - 遅延や障害の検知とアラート設定 6. バックアップ戦略 - 定期的なフルバックアップとバイナリログの保存 - ポイントインタイムリカバリの準備 7. 接続管理 - プロキシソフトウェア（例：ProxySQL）の導⼊ 検討 - アプリケーションからの接続の抽象化 8. ⽔平スケーリング - 読み取り専⽤のレプリカを増設し負荷分散による パフォーマンス改善と可⽤性向上 IBUFOBJOUFSO !"
33. ࢀߟ: ϚωʔδυαʔϏεΛ׆༻͢Δ • クラウドで利⽤する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 !!
34. ΞϓϦ૚ IBUFOBJOUFSO !"
35. アプリケーション層の冗⻑化の概要 1/2 ⼿順 説明 1. 複数インスタンスの作成 同⼀構成のアプリケーションサーバを複数の 異なるサーバーまたはコンテナで稼働 2. ロードバランサーの導⼊ LBでトラフィックを複数のアプリケーション インスタンスに分散 3. セッション管理 セッション情報を外部ストレージ（例： Redis）で⼀元管理 4. キャッシュの共有 アプリケーションキャッシュを外部サービス （例：Memcached）で共有 IBUFOBJOUFSO !"
36. アプリケーション層の冗⻑化の概要 2/2 ⼿順 説明 5. 設定の⼀元管理 設定情報を外部サービス（例：etcd, Consul）で管理し、動的に更新 6. ヘルスチェックの実装 各インスタンスの状態を定期的に確認し、問 題のあるインスタンスを⾃動的に切り離し 7. ⾃動⽔平スケーリングの設定 負荷に応じて⾃動的にインスタンス数を増減 させる 8. ログの集中管理 各インスタンスのログを中央のログサーバー に集約 IBUFOBJOUFSO !"
37. WEB૚ IBUFOBJOUFSO !"
38. WEBサーバ層の冗⻑化の概要 1/2 ⼿順 説明 1. 複数のWEBサーバ構築 同⼀構成のWEBサーバを複数台⽤意 2. ロードバランサーの導⼊ LBでトラフィックを複数のWEBサー バに分散 3. セッション管理 セッション情報を共有ストレージで管 理（必要な場合） 4. 静的コンテンツの配信最適化 CDNの導⼊や共有ストレージの利⽤ IBUFOBJOUFSO !"
39. WEBサーバ層の冗⻑化の概要 2/2 ⼿順 説明 %. SSL/TLS終端の設定 ロードバランサーでSSL/TLS終端を⾏う 6. ヘルスチェックの実装 各インスタンスの状態を定期的に確認 し、問題のあるインスタンスを⾃動的 に切り離し 7. ⾃動⽔平スケーリングの設定 負荷に応じてWEBサーバ数を⾃動調整 8. ログの集中管理 各WEBサーバのログを中央で管理 IBUFOBJOUFSO !"
40. ࢀߟ: DNSϥ΢ϯυϩϏϯ • ドメイン名に複数のIPアドレスを割り当て、クライアントのDNSクエリに対して順番に異なるIPを返す • トラフィックを複数のサーバに分散させる • 特別な装置が不要でコスト効率が良い IBUFOBJOUFSO !"
41. DNSϥ΢ϯυϩϏϯͷ໰୊఺ • DNSキャッシュの影響で負荷が均等に分散されない場合がある • 故障したサーバのアドレスが返される可能性があり、可⽤性が 低下する IBUFOBJOUFSO !"
42. CDNͷಋೖ IBUFOBJOUFSO !"
43. CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 1/2 RASIS要素 CDN導⼊による効果 信頼性 (Reliability) - コンテンツ複製で冗⻑性向上 - 単⼀障害点の削減 - 分散配置でデータ損失リスク低減 可⽤性 (Availability) - 分散サーバーによる⾼可⽤性 - トラフィック負荷分散 - DDoS攻撃の影響軽減 保守性 (Serviceability) - 中央管理でコンテンツ更新容易 - トラフィック分析やログ管理改善 - スケーリング⾃動化 IBUFOBJOUFSO !"
44. CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 2/2 RASIS要素 CDN導⼊による効果 完全性 (Integrity) - コンテンツ⼀貫性確保 - データ転送整合性チェック - 最新データ提供のキャッシュ管理 セキュリティ (Security) - SSL/TLS暗号化⼀元管理 - WAF（Web Application Firewall） 提供 - アクセス制御とモニタリング強化 IBUFOBJOUFSO !!
45. ୅දతͳCDNϓϩόΠμʔ • Akamai • Cloudflare • Amazon CloudFront • Google Cloud CDN • Microsoft Azure CDN • さくらインターネット ウェブアクセラレータ IBUFOBJOUFSO !"
46. ߴՄ༻Λ֫ಘͨ͠Πϯϑϥͷྫ • 分散アーキテクチャの導⼊ • 冗⻑化、⽔平スケーリングの導⼊ • CDNの導⼊ IBUFOBJOUFSO !"
47. ߴՄ༻ੑΛ࣮ݱ͢ΔΫϥ΢υߏ੒(·ͱΊ) • なぜ⾼可⽤が必要か • モノリシック構成の課題：単⼀障害点∕スケール制限∕デプロイ‧保守の難しさ • どう設計するか（⽅向性） • 分散アーキテクチャへの移⾏ • 各層（Web∕App∕DB）の冗⻑化と⽔平スケーリング • CDNで配信最適化と負荷分散 ⾼可⽤構成は要素が増えて⼿作業では維持困難。そこでInfrastructure as Codeで環境をソフ トウェア化し、再現性‧変更管理‧ドリフト防⽌を実現する IBUFOBJOUFSO !"
48. Infrastructure as Code ͱࣗಈԽ IBUFOBJOUFSO !"
49. IaCʗࣗಈԽͱ͸Կ͔ʁ • 定義 • Infrastructure as Code：インフラ構成をコードで定義し、プログラムで作成‧ 管理する⼿法 • ⾃動化：コードやスクリプトでプロビジョニング→テスト→デプロイまで⼀気 通貫で実⾏ • 従来との違い • ⼿動設定 ⇔ コード実⾏ • ドキュメント依存 ⇔ Git 管理 IBUFOBJOUFSO !"
50. ͳͥ“ΠϯϑϥΛιϑτ΢ΣΞԽ”͢Δͷ͔ʁ • Infrastructure as Software の意義 • コードとして扱うことで「可読性」「差分管理」「再利⽤性」を実現 • 設定⼿順やナレッジを属⼈化させず、チーム全体で共通理解を担保 • 組織にもたらす効果 • 新規メンバーでも環境構築が即可能 • レビュー∕ロールバックが容易になり運⽤リスクを低減 IBUFOBJOUFSO !"
51. એݴతઃܭͷϝϦοτ • 望ましい状態をコードで宣⾔ • 「こうあるべき」を記述し、ツールに実現を任せる • ドリフト防⽌ • 実際の状態とコードとの差分（ドリフト）を⾃動検知‧是正 • 可読性と保守性の向上 • コードを追うだけで「何がどう構成されるか」が明確 • 再利⽤性の⾼いモジュール化 • 共通パターンをモジュール化し、複数環境で簡単に再利⽤ • チーム開発との親和性 • GitOps的な運⽤に組み込みやすい IBUFOBJOUFSO !"
52. ୅දతͳIaCπʔϧͱಛ௃ ツール 特徴 ユースケース例 Terraform 宣⾔的HCL∕マルチクラウド対応 ∕豊富なプロバイダ マルチクラウド∕ハイブリッド運 ⽤ CloudFormation AWS専⽤YAML/JSONテンプレート ∕Drift Detection機能 純AWS環境でのマネージドリソー ス構築 AWS CDK TypeScript/Python等で記述→CFN に変換∕⾼度抽象化ライブラリ 複雑ロジックをコードで表現した い場合 Pulumi 任意⾔語（Go, Java, .NET等）で IaC∕ハイブリッド宣⾔＋命令型 既存開発⾔語スキルを活かした導 ⼊ IBUFOBJOUFSO !"
53. CI/CD࿈ܞͱΨʔυϨʔϧ • PRベース運⽤ Git Push → ⾃動ビルド∕テスト → 差分プランの確認 → Code Review → ⾃動適⽤∕デプロイ → モニタリング • ⾃動検証 • Lint/Validate/Plan差分チェック • セキュリティスキャン（tfsec, Checkov） • Policy-as-Code（Open Policy Agent (OPA), Gatekeeper, Sentinel） IBUFOBJOUFSO !"
54. ӡ༻΁ͷམͱ͠ࠐΈϙΠϯτ • モジュール化∕共通化 役割ごとにモジュールを作り、再利⽤性を⾼める • 環境分離 dev/stage/prod をコードレベルで明確に切り分け • Secrets 管理 各クラウドや外部サービスが提供するシークレット管理機能（例：ク ラウドのマネージドSecretストア、Vaultなど）と連携して、機密情 報をコード外に隔離 IBUFOBJOUFSO !"
55. 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 !!
56. Infrastructure as Code ͱࣗಈԽ (·ͱΊ) • コード化で再現性と安定性を確保 ⼿動作業を排除し、いつでも同じ環境を構築可能にする • 宣⾔的設計で「望ましい状態」を⾃動維持 差分検知と⾃⼰修復により運⽤負荷を削減 • CI/CD連携でフィードバックループをまわす GitOps的なワークフローと統合し、安全かつ迅速な運⽤を実現 IBUFOBJOUFSO !"
57. ϞχλϦϯάͱΦϒβʔόϏϦςΟ IBUFOBJOUFSO !"
58. ͦ΋ͦ΋ʮݟ͑ΔԽʯ͕ͳͥେࣄ͔ʁ • サービス運⽤で⼀番困るのは「気づかない不具合」 • ユーザーが「遅い」「落ちる」と感じる前に、システムの異常 を早く⾒つけることが⼤切 • そのために モニタリング と オブザーバビリティ がある IBUFOBJOUFSO !"
59. ϞχλϦϯάͱ͸ • 定義：あらかじめ決めた指標（CPU、メモリ、レスポンス時間 など）を監視し、異常を検知すること • ⽬的：システムの「今の状態」を知る • 例： • CPU使⽤率が90%以上になったらアラート • エラーログが1分間に100件以上出たら通知 IBUFOBJOUFSO !"
60. ϞχλϦϯάͷݶք • CPUが⾼いことは分かるけど「なぜ⾼いのか」は分からない • サーバーやコンテナが増えると「どのノードで問題が起きたの か」特定が難しい • つまり 「何が起きているか」は分かるが、「なぜ起きたのか」 は分からない IBUFOBJOUFSO !"
61. ΦϒβʔόϏϦςΟͱ͸ʁ • 定義：システム内部で何が起きているかを「外から集めたデータ」か ら理解すること • ⽬的：「なぜ遅いのか∕どこで失敗しているのか」を素早く突き⽌め る • 必要な理由： • マイクロサービスやサーバレスなど複雑な構成が当たり前 • モニタリングだけでは「未知の異常」や「因果関係」が追えない IBUFOBJOUFSO !"
62. ϞχλϦϯάͱΦϒβʔόϏϦςΟͷҧ͍ 項⽬ モニタリング オブザーバビリティ ⽬的 状態を検知する 原因を理解する ⼿段 メトリクス∕ログ中⼼ MELT（Metrics / Events / Logs / Traces） 得意 「異常に気づく」 「なぜ異常が起きたか掘る」 例： - モニタリング → 「EC/のCPUが90%超」 - オブザーバビリティ → 「APIがボトルネック、特定クエリが遅延」 IBUFOBJOUFSO !"
63. MELTʢ4ͭͷபʣ • Metrics：リソース使⽤率やレスポンスタイムなど定量的指標 • Events：デプロイや障害などの出来事 • Logs：アプリやミドルウェアが出す詳細な履歴 • Traces：リクエストの流れを追跡（どのサービスが遅いか⼀⽬ で分かる IBUFOBJOUFSO !"
64. ಘΒΕΔޮՌ • 未知の異常に気づける（例：イベントとメトリクスの相関でデ プロイ由来の不具合を検知） • 原因調査が速い（トレースでボトルネック特定 → ログで詳細確 認 → メトリクスで影響範囲を把握） • 複雑な環境でも俯瞰できる（マイクロサービスや外部APIの依存 関係を⼀望） IBUFOBJOUFSO !"
65. MackerelͰ࣮ݱ͢ΔΦϒβʔόϏϦςΟ • Metrics：エージェントによる収集に加えて、OpenTelemetry形式 （OTLP）で送信されたメトリクスも取り込み可能 • Events：デプロイや障害といった出来事をグラフアノテーション としてメトリクスと関連づけて把握できる • Logs：ログについては対応を検討中 • Traces：OpenTelemetryからのトレースを受け取り、Vaxila(APM) でリクエスト単位の遅延やエラーを分析可能 IBUFOBJOUFSO !"
66. ඪ४ن֨ɿOpenTelemetry • OpenTelemetry は、モニタリングやオブザーバビリティのデータ収集を統⼀するためのオー プンソース規格 • できること： • 1つのSDKでメトリクス∕ログ∕トレースを収集 • ベンダーに依存せず、Mackerel‧Prometheus‧Jaegerなど多様なツールにデータを送れる • ポイント： • 将来ツールを乗り換えても計測の仕組みは使い回せる • 「オブザーバビリティの共通⾔語」として世界中で利⽤が広がっている IBUFOBJOUFSO !!
67. ϞχλϦϯάͱΦϒβʔόϏϦςΟ (·ͱΊ) • モニタリング：状態を「知る」仕組み • オブザーバビリティ：原因を「理解する」仕組み • 最終的なゴールは 「ユーザーに影響する前に異常を検知し、す ぐに直せる体制」 を作ること IBUFOBJOUFSO !"
68. DevOpsʗSREೖ໳ IBUFOBJOUFSO !"
69. DevOpsʗSREͷ֓ཁ • DevOps：開発と運⽤を統合し、迅速なデリバリーと改善を実 現する⽂化 • SRE：Google発の信頼性エンジニアリング。運⽤をソフトウェ ア化し、速度と可⽤性を両⽴ • 位置づけ：SREはDevOpsを実現する⼿法の⼀つ • 共通点：⾃動化と可観測性で、品質とスピードを両⽴ IBUFOBJOUFSO !"
70. DevOpsʗSRE͕ॏࢹ͢Δ͜ͱ • 信頼性の設計と維持（可⽤性‧性能‧耐障害性） • 変更の安全性とスピード（IaC∕CI/CD、ロールバック） • 可観測性の確⽴（MELT基盤、ダッシュボード、アラート） • インシデント対応（オンコール→復旧→Postmortem） • コスト‧キャパシティ‧セキュリティ管理（オートスケール、 コスト可視化、Policy as Code） IBUFOBJOUFSO !"
71. ৴པੑΛͲ͏ଌΔ͔ʁ 「信頼性」「変更の安全性」を実際に管理するには、数値での⽬ 標設定が必要 • 「どのくらい成功すればよいか？」 • 「どのくらい失敗を許せるか？」 → SLI∕SLO∕エラーバジェット IBUFOBJOUFSO !"
72. SLIʗSLOʗΤϥʔόδΣοτ • SLI：品質を数値で測る指標（例：リクエスト成功率、レスポン スタイム） • SLO：その指標に対する⽬標（例：リクエスト成功率99.9%） • エラーバジェット：許容される失敗率 → 開発速度と信頼性の調 整に使う 単なる数値ではなく「リリースや改善の判断材料」になる IBUFOBJOUFSO !"
73. Քಇ཰ͱՄ༻ੑ 稼働率 ＝（総稼動時間−障害時間）/ 総稼動時間 × 100 例）30⽇間（()*h）で障害10h → !".$%% → 数字が同じでも「いつ⽌まったか」でエンドユーザーの体感品 質は変わる（例：業務時間の停⽌は深夜より影響が⼤きい） IBUFOBJOUFSO !"
74. ࢀߟɿ X-Nines ͱڐ༰Մೳμ΢ϯλΠϜ Մ༻ੑ໨ඪͱμ΢ϯλΠϜ 可⽤性 年間 ⽉間 週間 ((% 3.6⽇ ../h 1..h ((.(% 2..h 34m 16m ((.((% 74m 3m 1m ((.(((% 7m /8s 8s → 「⾼可⽤性」ほどコストや仕組みが複雑になる（例：冗⻑化インフラ、マルチリージョン構成、マルチクラウド構成） IBUFOBJOUFSO !"
75. SLAͱ͸ʁ • SLA (Service Level Agreement)：サービス提供者と利⽤者の間で合意される可⽤性保証 • 例：⽉間稼働率99.9%以上を保証、下回った場合はクレジット付与 • 公開される場合もあれば、⾮公開のサービスも多い ެ։ྫ • AWS：サービス別 SLA • Google Workspace：SLA • さくらクラウド：SLA IBUFOBJOUFSO !"
76. Մ༻ੑ͕ߴ͍ͱԿ͕خ͍͔͠ • ユーザ体験向上：いつでも使える • ビジネス継続性：⽌まらない仕組み • 信頼性向上：安⼼して任せられる IBUFOBJOUFSO !"
77. Ͳ͏؂ࢹ͠ଓ͚Δ͔ʁ 可⽤性やSLAで⽬標を決めても、それを継続的に測定‧評価でき なければ意味がない → ここで重要になるのが オブザーバビリティ IBUFOBJOUFSO !!
78. ΦϒβʔόϏϦςΟͷӡ༻ • 既存メトリクス∕ログの活⽤と拡充 • カスタムメトリクス追加、JSONログ化 • SLI/SLO、エラーバジェット等のダッシュボード作成、アラー ト設定 • Postmortemで失敗を学び改善 • 定期レビューで閾値‧項⽬を更新 IBUFOBJOUFSO !"
79. DevOpsʗSREೖ໳ (·ͱΊ) • DevOps∕SRE：⾃動化と可観測性で品質と速度を両⽴ • SLI∕SLO∕エラーバジェット：数値を使い運⽤判断を明確化 • 可⽤性とSLA：⽬標値と保証の関係を理解する • オブザーバビリティ：計測→可視化→改善のサイクルが鍵 • 技術だけでなく 「信頼性を守る姿勢」 が⼤切 IBUFOBJOUFSO !"
80. ·ͱΊ • クラウドコンピューティング概論 • ⾼可⽤性を実現するクラウド構成 • Infrastructure as Code と⾃動化 • モニタリングとオブザーバビリティ • DevOps∕SRE⼊⾨ についてお話しました IBUFOBJOUFSO !"