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

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

Hatena
October 31, 2024
650

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

Hatena

October 31, 2024
Tweet

More Decks by Hatena

Transcript

  1. ࣗݾ঺հ • はてなid: k*s*eee • 株式会社はてな • 組織基盤‧開発本部 プラットフォーム部 •

    システムプラットフォームチーム SRE • 所属オフィス • 東京オフィス(ほぼフルリモート勤務) • 好きなAWSサービス • EC_ • 趣味 • ゲーム、映画、ソロキャンプ IBUFOBJOUFSO !
  2. ͜ͷߨٛͰ࿩͢͜ͱ • インフラの概観 • RASIS • ⾼可⽤に向けたアプローチ • 可⽤性の低いインフラ構成の例 •

    ⾼可⽤を獲得したインフラの例 • モニタリングとアラート IBUFOBJOUFSO !
  3. WEBαʔϏεͷΠϯϑϥ 'WEB System' - ( 'Application' + 'Data' ) =

    'Infra' • アプリケーションを動かすための⼟台となるもの IBUFOBJOUFSO !
  4. Մ༻ੑ: Քಇ཰ܭࢉͷྫ 稼働率 =(総稼動時間−累計障害時間)/ 総稼動時間 * 100 γεςϜͷ30೔ؒͰͷՔಇ཰Λܭࢉ͢Δྫ • 総稼動時間:

    30day = /0h * 34day = 5/4h • 累計障害時間: 10h • 稼働率: (5/4h - ?4h) / 5/4h * ?44 = BC.E?% IBUFOBJOUFSO !"
  5. 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 (<N) 52.56 分 4.32 分 4.032 分 2.016 分 1.008 分 00.000 (=N) 5.256 分 25.92 秒 24.192 秒 12.096 秒 6.048 秒 IBUFOBJOUFSO !"
  6. ࢀߟ: ެ։͞Ε͍ͯΔ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 !"
  7. ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 1/2 課題 説明 単⼀障害点 ⼀部の障害がシステム全体を停⽌させるリス ク スケーラビリティの制限 システム全体のスケールアップが必要で、リ ソース効率が悪い

    チーム開発の⾮効率 複数のチームでの同時作業が困難 デプロイの難しさ ⼩さな変更でも全体の再デプロイが必要で、 ダウンタイムが発⽣ IBUFOBJOUFSO !"
  8. ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 2/2 課題 説明 開発の複雑性 コードが⼤規模化し、管理や変更が困難 保守性の低下 コードの品質が低下しやすく、リファクタリ ングが困難 技術スタックの制限

    全体が同じ技術に依存し、最適な技術選択が 難しい 起動時間の増加 アプリケーションが⼤きくなるとシステム起 動までの時間が⻑くなる IBUFOBJOUFSO !"
  9. ຊ೔͓࿩͢ΔߴՄ༻ʹ޲͚ͨΞϓϩʔν アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性)

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

    S (セキュリティ) テスト/デプロイ⾃動化 (CI/CD) ✓ 運⽤⼿順の⽂書化 ✓ バックアップ戦略の強 化 ✓ ✓ トランザクション管理 の強化 ✓ データ整合性チェック の導⼊ ✓ アクセス制御と認証の 強化 ✓ 暗号化の導⼊ ✓ IBUFOBJOUFSO !"
  11. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 1/3 メリット 説明 スケーラビリティ 個別のコンポーネントやサービスを独⽴してスケー ルアップ/ダウンが可能 柔軟性 新技術の導⼊や既存コンポーネントの更新が容易 耐障害性

    ⼀部のコンポーネントの障害が全体に波及しにくい 構造 開発の効率化 ⼩規模なチームが独⽴して開発可能、並⾏開発が容 易 技術の多様性 各コンポーネントに最適な技術スタックを選択可能 IBUFOBJOUFSO !"
  12. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 2/3 メリット 説明 継続的デプロイ 個別のコンポーネントを独⽴してデプロイ可能 保守性 ⼩規模なコンポーネントは理解や保守が容易 チーム開発の効率化 個別のコンポーネントごとに開発チームを分けると

    いった事が可能になり開発効率が上がる リソース最適化 必要なコンポーネントのみをスケールアップし、リ ソースを効率的に利⽤ サービスの再利⽤ 共通のサービスを複数のアプリケーションで再利⽤ 可能 IBUFOBJOUFSO !"
  13. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 3/3 メリット 説明 パフォーマンス向上 負荷分散やキャッシュの効果的な利⽤が可能 セキュリティの強化 コンポーネント間の境界でのセキュリティ制 御が可能、影響範囲の限定化 アクセス制御の粒度

    各サービスやコンポーネントに対して細かな アクセス制御が可能 セキュリティ更新の容易さ 個別のコンポーネントに対して迅速にセキュ リティパッチを適⽤可能 IBUFOBJOUFSO !"
  14. ৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 1/2 課題 説明 複雑性の増加 システム全体の設計‧管理が複雑化し、運⽤の難易度が上がる 通信オーバーヘッド コンポーネント間の通信が増加し、レイテンシやネットワーク 負荷が増⼤ データの整合性維持

    分散されたデータの⼀貫性を保つことが難しくなる トランザクション管理 複数のサービスにまたがるトランザクションの管理が複雑にな る テストの複雑化 統合テストや全体的なシステムテストが難しくなる 開発‧運⽤コストの増加 初期の開発コストや継続的な運⽤コストが増加する可能性があ る IBUFOBJOUFSO !!
  15. ৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 2/2 課題 説明 スキル要件の変化 開発者や運⽤チームに新しいスキルセットが要求される モニタリングの複雑化 分散されたシステムの監視と問題の特定が難しくなる セキュリティの複雑化 攻撃対象⾯が増加し、セキュリティ管理が複雑になる

    ネットワーク依存性 ネットワークの信頼性と性能がシステム全体に⼤きく影 響する バージョン管理の複雑化 異なるサービス間の互換性維持が難しくなる デバッグの困難さ 問題の根本原因の特定と修正が複雑になる IBUFOBJOUFSO !"
  16. MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 1/2 ⼿順 説明 1. マスター‧スレーブ構成 - 1台のマスターDBと複数のスレーブDBを設置 - マスターDBは書き込み/読み取り、スレーブDBは読

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

    6. バックアップ戦略 - 定期的なフルバックアップとバイナリログの保存 - ポイントインタイムリカバリの準備 7. 接続管理 - プロキシソフトウェア(例:ProxySQL)の導⼊ 検討 - アプリケーションからの接続の抽象化 8. ⽔平スケーリング - 読み取り専⽤のレプリカを増設し負荷分散による パフォーマンス改善と可⽤性向上 IBUFOBJOUFSO !"
  18. アプリケーション層の冗⻑化の概要 1/2 ⼿順 説明 1. 複数インスタンスの作成 同⼀構成のアプリケーションサーバを複数の 異なるサーバーまたはコンテナで稼働 2. ロードバランサーの導⼊

    LBでトラフィックを複数のアプリケーション インスタンスに分散 3. セッション管理 セッション情報を外部ストレージ(例: Redis)で⼀元管理 4. キャッシュの共有 アプリケーションキャッシュを外部サービス (例:Memcached)で共有 IBUFOBJOUFSO !"
  19. アプリケーション層の冗⻑化の概要 2/2 ⼿順 説明 5. 設定の⼀元管理 設定情報を外部サービス(例:etcd, Consul)で管理し、動的に更新 6. ヘルスチェックの実装

    各インスタンスの状態を定期的に確認し、問 題のあるインスタンスを⾃動的に切り離し 7. ⾃動⽔平スケーリングの設定 負荷に応じて⾃動的にインスタンス数を増減 させる 8. ログの集中管理 各インスタンスのログを中央のログサーバー に集約 IBUFOBJOUFSO !"
  20. WEBサーバ層の冗⻑化の概要 1/2 ⼿順 説明 1. 複数のWEBサーバ構築 同⼀構成のWEBサーバを複数台⽤意 2. ロードバランサーの導⼊ LBでトラフィックを複数のWEBサー

    バに分散 3. セッション管理 セッション情報を共有ストレージで管 理(必要な場合) 4. 静的コンテンツの配信最適化 CDNの導⼊や共有ストレージの利⽤ IBUFOBJOUFSO !"
  21. WEBサーバ層の冗⻑化の概要 2/2 ⼿順 説明 %. SSL/TLS終端の設定 ロードバランサーでSSL/TLS終端を⾏う 6. ヘルスチェックの実装 各インスタンスの状態を定期的に確認

    し、問題のあるインスタンスを⾃動的 に切り離し 7. ⾃動⽔平スケーリングの設定 負荷に応じてWEBサーバ数を⾃動調整 8. ログの集中管理 各WEBサーバのログを中央で管理 IBUFOBJOUFSO !"
  22. CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 1/2 RASIS要素 CDN導⼊による効果 信頼性 (Reliability) - コンテンツ複製で冗⻑性向上 - 単⼀障害点の削減

    - 分散配置でデータ損失リスク低減 可⽤性 (Availability) - 分散サーバーによる⾼可⽤性 - トラフィック負荷分散 - DDoS攻撃の影響軽減 保守性 (Serviceability) - 中央管理でコンテンツ更新容易 - トラフィック分析やログ管理改善 - スケーリング⾃動化 IBUFOBJOUFSO !"
  23. CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 2/2 RASIS要素 CDN導⼊による効果 完全性 (Integrity) - コンテンツ⼀貫性確保 - データ転送整合性チェック

    - 最新データ提供のキャッシュ管理 セキュリティ (Security) - SSL/TLS暗号化⼀元管理 - WAF(Web Application Firewall) 提供 - アクセス制御とモニタリング強化 IBUFOBJOUFSO !"
  24. ୅දతͳCDNϓϩόΠμʔ • Akamai • Cloudflare • Amazon CloudFront • Google

    Cloud CDN • Microsoft Azure CDN • さくらインターネット ウェブアクセラレータ IBUFOBJOUFSO !"
  25. ϞχλϦϯάͱΞϥʔτͷಋೖʹΑΔRASIS΁ͷظ଴ޮՌ モニタリングとアラート導⼊による期待効果 1/2 RASIS要素 期待効果 信頼性 (Reliability) - 問題の早期発⾒と迅速な対応 -

    システム動作の継続的な監視による安定性向上 可⽤性 (Availability) - ダウンタイムの最⼩化 - パフォーマンス低下の事前検知と対応 保守性 (Serviceability) - トラブルシューティングの効率化 - 予防的なメンテナンスの実現 IBUFOBJOUFSO !!
  26. モニタリングとアラート導⼊による期待効果 2/2 RASIS要素 期待効果 完全性 (Integrity) - データの整合性チェックの⾃ 動化 -

    異常なデータ操作の検知 セキュリティ (Security) - セキュリティ侵害の早期検知 - 異常なアクセスパターンの識別 IBUFOBJOUFSO !"
  27. ࢀߟ: SRE(Site Reliability Engineering)ʹ͍ͭͯ • サイト‧リライアビリティ‧エンジニアリング(英:Site Reliability Engineering、略: SRE)は、Google社が提唱、実践しているシステム管理とサービス運⽤の⽅法論である。 サイト信頼性エンジニアリングと訳される場合もある。また、サイトリライアビリティエン

    ジニアリングを担当するエンジニアをサイトリライアビリティエンジニア(SRE)と呼ぶ。 • SREは、主に ⾃動化、モニタリング、インシデント管理、キャパシティプランニング、パフ ォーマンス最適化など信頼性向上に向けた改善を継続的に⾏い、速度と信頼性のバランスを 取ることに注⼒します。 • システムが常に利⽤可能であるだけでなく、期待通りに機能し、ユーザーの信頼に応えられ るよう努め、複雑化するインフラを効果的に運⽤し、ビジネスの成功を技術⾯からサポート します。 IBUFOBJOUFSO !!
  28. ·ͱΊ • インフラの概観 • RASIS • ⾼可⽤に向けたアプローチ • サービス初期のインフラ •

    ⾼可⽤を獲得したインフラの例 • モニタリングとアラート についてお話しました IBUFOBJOUFSO !"