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

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

Transcript

1. ߴՄ༻ੑΛҙࣝͨ͠WEBΠϯϑϥ IBUFOBJOUFSO !
2. ͸͡Ίʹ IBUFOBJOUFSO !
3. • ⾃⼰紹介 • この講義について IBUFOBJOUFSO !
4. ࣗݾ঺հ • はてなid: k*s*eee • 株式会社はてな • 組織基盤‧開発本部 プラットフォーム部 • システムプラットフォームチーム SRE • 所属オフィス • 東京オフィス（ほぼフルリモート勤務） • 好きなAWSサービス • EC_ • 趣味 • ゲーム、映画、ソロキャンプ IBUFOBJOUFSO !
5. ͜ͷߨٛͰ࿩͢͜ͱ • インフラの概観 • RASIS • ⾼可⽤に向けたアプローチ • 可⽤性の低いインフラ構成の例 • ⾼可⽤を獲得したインフラの例 • モニタリングとアラート IBUFOBJOUFSO !
6. Πϯϑϥͷ֓؍ IBUFOBJOUFSO !
7. ޿ٛͷΠϯϑϥ インフラとは、社会や経済、あるいは国⺠ ⽣活が拠って⽴つ基盤となる、必要不可⽋ な施設やサービス、機関、制度、仕組みな どのこと。“infrastructure” は「基盤」 「下部構造」などの意味を持つ英単語で、 外来語としては「インフラ」という略語が 定着している。 -- https://e-words.jp/w/インフラ.html • ⽣活や産業の基盤となる設備‧施設 • ⽔道、電気、ガス、道路など IBUFOBJOUFSO !
8. WEBαʔϏεͷΠϯϑϥ 'WEB System' - ( 'Application' + 'Data' ) = 'Infra' • アプリケーションを動かすための⼟台となるもの IBUFOBJOUFSO !
9. Πϯϑϥͷओͳߏ੒ཁૉ サーバ CPU,メモリ など ストレージ HDD, SSD, エフェメラルストレージ など ネットワーク NIC,VPC など ソフトウェア 各種OS、各種ミドルウェア など IBUFOBJOUFSO !
10. RASIS RASIS（レイシス、ラシスと読む）は機器、シスムやコンピュータ等の総合的な評価指数 コンピュータシステムに関する評価指標の頭⽂字を並べたもの 特に最初の3つをRASという • Reliability（信頼性） • Availability（可⽤性） • Serviceability（保守性） • Integrity（完全性） • Security（機密性） IBUFOBJOUFSO !"
11. Reliabilityʢ৴པੑʣ • システムが故障やエラーなく動作し続ける能⼒。 • 例: サーバやネットワーク機器が⻑期間安定して動作すること。 • 代表的な評価指数: • 平均故障間隔（Mean Time Between Failures、MTBF） IBUFOBJOUFSO !!
12. AvailabilityʢՄ༻ੑʣ • システムが利⽤可能な時間の割合。 • 例: サーバの稼働率、ウェブサイトがユーザーに常時アクセス可 能であること。 • 代表的な評価指数 • 稼働率 =（総稼動時間 − 累計障害時間）/ 総稼動時間 * 100 この講義では可⽤性に注⽬します IBUFOBJOUFSO !"
13. Serviceabilityʢอकੑʣ • システムの修理やメンテナンスの容易さ。 • 例: ハードウェアの修理時間の短縮、ソフトウェアのアップデー トの容易さ。 • 代表的な評価指数: • 平均修理時間（Mean Time To Repair、MTTR） IBUFOBJOUFSO !"
14. Integrityʢ׬શੑʣ • データやシステムの正確性と⼀貫性が保たれていること。 • 例: データの改ざん防⽌、トランザクションの⼀貫性の確保。 IBUFOBJOUFSO !"
15. Securityʢػີੑʣ • システムやデータが不正アクセスや攻撃から保護されているこ と。 • 例: データ暗号化、認証と認可の仕組み。 IBUFOBJOUFSO !"
16. Մ༻ੑ: Քಇ཰ܭࢉͷྫ 稼働率 ＝（総稼動時間−累計障害時間）/ 総稼動時間 * 100 γεςϜͷ30೔ؒͰͷՔಇ཰Λܭࢉ͢Δྫ • 総稼動時間: 30day = /0h * 34day = 5/4h • 累計障害時間: 10h • 稼働率: (5/4h - ?4h) / 5/4h * ?44 = BC.E?% IBUFOBJOUFSO !"
17. 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 !"
18. ࢀߟ: ެ։͞Ε͍ͯΔ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 !"
19. Մ༻ੑ͕ߴ͍ͱԿ͕خ͍͔͠ • ユーザの体験が向上する • ビジネスの継続性が向上する • ユーザ、ビジネスサイドからの信頼性が向上する IBUFOBJOUFSO !"
20. ߴՄ༻ʹ޲͚ͨΞϓϩʔν IBUFOBJOUFSO !"
21. খن໛ͳαʔϏεͷΠϯϑϥߏ੒ͷྫ • 新しいWEBサービスを開発したときのインフラ構成の例です • WEBシステムの機能を1台のサーバに全て詰め込むモノリシックアーキテクチャ（Monolithic Architecture）でサービスを開始しました IBUFOBJOUFSO !"
22. ϞϊϦγοΫΞʔΩςΫνϟͰͷ՝୊ IBUFOBJOUFSO !!
23. ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 1/2 課題 説明 単⼀障害点 ⼀部の障害がシステム全体を停⽌させるリス ク スケーラビリティの制限 システム全体のスケールアップが必要で、リ ソース効率が悪い チーム開発の⾮効率 複数のチームでの同時作業が困難 デプロイの難しさ ⼩さな変更でも全体の再デプロイが必要で、 ダウンタイムが発⽣ IBUFOBJOUFSO !"
24. ϞϊϦγοΫΞʔΩςΫνϟͷओͳ՝୊ 2/2 課題 説明 開発の複雑性 コードが⼤規模化し、管理や変更が困難 保守性の低下 コードの品質が低下しやすく、リファクタリ ングが困難 技術スタックの制限 全体が同じ技術に依存し、最適な技術選択が 難しい 起動時間の増加 アプリケーションが⼤きくなるとシステム起 動までの時間が⻑くなる IBUFOBJOUFSO !"
25. Մ༻ੑΛ޲্ͤ͞ΔΞϓϩʔν IBUFOBJOUFSO !"
26. ຊ೔͓࿩͢ΔߴՄ༻ʹ޲͚ͨΞϓϩʔν アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性) S (セキュリティ) 分散アーキテク チャの導⼊ ✓ ✓ ✓ 冗⻑化、⽔平ス ケーリングの導 ⼊ ✓ ✓ CDNの導⼊ ✓ ✓ ✓ モニタリングと アラート ✓ IBUFOBJOUFSO !"
27. ͦͷଞͷΞϓϩʔνͷྫ アプローチ R (信頼性) A (可⽤性) S (保守性) I (完全性) S (セキュリティ) テスト/デプロイ⾃動化 (CI/CD) ✓ 運⽤⼿順の⽂書化 ✓ バックアップ戦略の強 化 ✓ ✓ トランザクション管理 の強化 ✓ データ整合性チェック の導⼊ ✓ アクセス制御と認証の 強化 ✓ 暗号化の導⼊ ✓ IBUFOBJOUFSO !"
28. ෼ࢄΞʔΩςΫνϟʢDistributed Architectureʣͷಋೖ IBUFOBJOUFSO !"
29. ϞϊϦγοΫΞʔΩςΫνϟ͔Β෼ࢄΞʔΩςΫνϟ΁มߋ͢Δ IBUFOBJOUFSO !"
30. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 1/3 メリット 説明 スケーラビリティ 個別のコンポーネントやサービスを独⽴してスケー ルアップ/ダウンが可能 柔軟性 新技術の導⼊や既存コンポーネントの更新が容易 耐障害性 ⼀部のコンポーネントの障害が全体に波及しにくい 構造 開発の効率化 ⼩規模なチームが独⽴して開発可能、並⾏開発が容 易 技術の多様性 各コンポーネントに最適な技術スタックを選択可能 IBUFOBJOUFSO !"
31. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 2/3 メリット 説明 継続的デプロイ 個別のコンポーネントを独⽴してデプロイ可能 保守性 ⼩規模なコンポーネントは理解や保守が容易 チーム開発の効率化 個別のコンポーネントごとに開発チームを分けると いった事が可能になり開発効率が上がる リソース最適化 必要なコンポーネントのみをスケールアップし、リ ソースを効率的に利⽤ サービスの再利⽤ 共通のサービスを複数のアプリケーションで再利⽤ 可能 IBUFOBJOUFSO !"
32. ෼ࢄΞʔΩςΫνϟΛ࠾༻͢ΔࣄͰಘΒΕΔར఺ 3/3 メリット 説明 パフォーマンス向上 負荷分散やキャッシュの効果的な利⽤が可能 セキュリティの強化 コンポーネント間の境界でのセキュリティ制 御が可能、影響範囲の限定化 アクセス制御の粒度 各サービスやコンポーネントに対して細かな アクセス制御が可能 セキュリティ更新の容易さ 個別のコンポーネントに対して迅速にセキュ リティパッチを適⽤可能 IBUFOBJOUFSO !"
33. ৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 1/2 課題 説明 複雑性の増加 システム全体の設計‧管理が複雑化し、運⽤の難易度が上がる 通信オーバーヘッド コンポーネント間の通信が増加し、レイテンシやネットワーク 負荷が増⼤ データの整合性維持 分散されたデータの⼀貫性を保つことが難しくなる トランザクション管理 複数のサービスにまたがるトランザクションの管理が複雑にな る テストの複雑化 統合テストや全体的なシステムテストが難しくなる 開発‧運⽤コストの増加 初期の開発コストや継続的な運⽤コストが増加する可能性があ る IBUFOBJOUFSO !!
34. ৔߹ʹΑΓσϝϦοτͱͳΔ՝୊ 2/2 課題 説明 スキル要件の変化 開発者や運⽤チームに新しいスキルセットが要求される モニタリングの複雑化 分散されたシステムの監視と問題の特定が難しくなる セキュリティの複雑化 攻撃対象⾯が増加し、セキュリティ管理が複雑になる ネットワーク依存性 ネットワークの信頼性と性能がシステム全体に⼤きく影 響する バージョン管理の複雑化 異なるサービス間の互換性維持が難しくなる デバッグの困難さ 問題の根本原因の特定と修正が複雑になる IBUFOBJOUFSO !"
35. ৑௕ԽɺਫฏεέʔϦϯάͷಋೖ IBUFOBJOUFSO !"
36. 3૚ߏ଄ͷ֤૚Λ৑௕Խͯ͠Մ༻ੑΛߴΊΔ 冗⻑化と合わせて⽔平スケーリングも導⼊する事で可⽤性と信頼 性が⼤きく改善される • DB層の冗⻑化、⽔平スケーリング • アプリ層の冗⻑化、⽔平スケーリング • WEBサーバ層の冗⻑化、⽔平スケーリング IBUFOBJOUFSO !"
37. DB૚ IBUFOBJOUFSO !"
38. MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 1/2 ⼿順 説明 1. マスター‧スレーブ構成 - 1台のマスターDBと複数のスレーブDBを設置 - マスターDBは書き込み/読み取り、スレーブDBは読 み取り専⽤ 2. レプリケーションの設定 - マスターからスレーブへのデータ複製を設定 - ⾮同期レプリケーションが⼀般的 3. 負荷分散 - アプリケーションの読み取りクエリをスレーブDBに 分散 - 書き込みはマスターDBで集中管理 4. フェイルオーバーの準備 - マスター障害時にスレーブを昇格させる仕組みを⽤意 - ⾃動/⼿動切り替えの選択 IBUFOBJOUFSO !"
39. MySQLを例にデータベース層の冗⻑化を⾏う場合の概要 2/2 ⼿順 説明 5. 監視とアラート - レプリケーション状態の常時監視 - 遅延や障害の検知とアラート設定 6. バックアップ戦略 - 定期的なフルバックアップとバイナリログの保存 - ポイントインタイムリカバリの準備 7. 接続管理 - プロキシソフトウェア（例：ProxySQL）の導⼊ 検討 - アプリケーションからの接続の抽象化 8. ⽔平スケーリング - 読み取り専⽤のレプリカを増設し負荷分散による パフォーマンス改善と可⽤性向上 IBUFOBJOUFSO !"
40. ࢀߟ: ϚωʔδυαʔϏεΛ׆༻͢Δ • クラウドで利⽤するDBにおいては、マネージドサービスを活⽤ すると冗⻑化機能を簡単に利⽤する事ができる場合が多い • クラウドベンダーの提供しているマネージドサービスを積極的 に活⽤してみると良い IBUFOBJOUFSO !"
41. ΞϓϦ૚ IBUFOBJOUFSO !"
42. アプリケーション層の冗⻑化の概要 1/2 ⼿順 説明 1. 複数インスタンスの作成 同⼀構成のアプリケーションサーバを複数の 異なるサーバーまたはコンテナで稼働 2. ロードバランサーの導⼊ LBでトラフィックを複数のアプリケーション インスタンスに分散 3. セッション管理 セッション情報を外部ストレージ（例： Redis）で⼀元管理 4. キャッシュの共有 アプリケーションキャッシュを外部サービス （例：Memcached）で共有 IBUFOBJOUFSO !"
43. アプリケーション層の冗⻑化の概要 2/2 ⼿順 説明 5. 設定の⼀元管理 設定情報を外部サービス（例：etcd, Consul）で管理し、動的に更新 6. ヘルスチェックの実装 各インスタンスの状態を定期的に確認し、問 題のあるインスタンスを⾃動的に切り離し 7. ⾃動⽔平スケーリングの設定 負荷に応じて⾃動的にインスタンス数を増減 させる 8. ログの集中管理 各インスタンスのログを中央のログサーバー に集約 IBUFOBJOUFSO !"
44. WEB૚ IBUFOBJOUFSO !!
45. WEBサーバ層の冗⻑化の概要 1/2 ⼿順 説明 1. 複数のWEBサーバ構築 同⼀構成のWEBサーバを複数台⽤意 2. ロードバランサーの導⼊ LBでトラフィックを複数のWEBサー バに分散 3. セッション管理 セッション情報を共有ストレージで管 理（必要な場合） 4. 静的コンテンツの配信最適化 CDNの導⼊や共有ストレージの利⽤ IBUFOBJOUFSO !"
46. WEBサーバ層の冗⻑化の概要 2/2 ⼿順 説明 %. SSL/TLS終端の設定 ロードバランサーでSSL/TLS終端を⾏う 6. ヘルスチェックの実装 各インスタンスの状態を定期的に確認 し、問題のあるインスタンスを⾃動的 に切り離し 7. ⾃動⽔平スケーリングの設定 負荷に応じてWEBサーバ数を⾃動調整 8. ログの集中管理 各WEBサーバのログを中央で管理 IBUFOBJOUFSO !"
47. ࢀߟ: DNSϥ΢ϯυϩϏϯ • ドメイン名に複数のIPアドレスを割り当て、クライアントのDNSクエリに対して順番に異なるIPを返す • トラフィックを複数のサーバに分散させる • 特別な装置が不要でコスト効率が良い IBUFOBJOUFSO !"
48. DNSϥ΢ϯυϩϏϯͷ໰୊఺ • DNSキャッシュの影響で負荷が均等に分散されない場合がある • 故障したサーバのアドレスが返される可能性があり、可⽤性が 低下する IBUFOBJOUFSO !"
49. CDNͷಋೖ IBUFOBJOUFSO !"
50. CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 1/2 RASIS要素 CDN導⼊による効果 信頼性 (Reliability) - コンテンツ複製で冗⻑性向上 - 単⼀障害点の削減 - 分散配置でデータ損失リスク低減 可⽤性 (Availability) - 分散サーバーによる⾼可⽤性 - トラフィック負荷分散 - DDoS攻撃の影響軽減 保守性 (Serviceability) - 中央管理でコンテンツ更新容易 - トラフィック分析やログ管理改善 - スケーリング⾃動化 IBUFOBJOUFSO !"
51. CDNͷಋೖʹΑΔRASISʢ৴པੑɺՄ༻ੑɺอकੑɺ׬શੑɺηΩϡϦςΟʣ΁ͷظ଴ޮՌ 2/2 RASIS要素 CDN導⼊による効果 完全性 (Integrity) - コンテンツ⼀貫性確保 - データ転送整合性チェック - 最新データ提供のキャッシュ管理 セキュリティ (Security) - SSL/TLS暗号化⼀元管理 - WAF（Web Application Firewall） 提供 - アクセス制御とモニタリング強化 IBUFOBJOUFSO !"
52. ୅දతͳCDNϓϩόΠμʔ • Akamai • Cloudflare • Amazon CloudFront • Google Cloud CDN • Microsoft Azure CDN • さくらインターネット ウェブアクセラレータ IBUFOBJOUFSO !"
53. ߴՄ༻Λ֫ಘͨ͠Πϯϑϥͷྫ • 分散アーキテクチャの導⼊ • 冗⻑化、⽔平スケーリングの導⼊ • CDNの導⼊ IBUFOBJOUFSO !"
54. ϞχλϦϯάͱΞϥʔτͷಋೖ IBUFOBJOUFSO !"
55. ϞχλϦϯάͱΞϥʔτͷಋೖʹΑΔRASIS΁ͷظ଴ޮՌ モニタリングとアラート導⼊による期待効果 1/2 RASIS要素 期待効果 信頼性 (Reliability) - 問題の早期発⾒と迅速な対応 - システム動作の継続的な監視による安定性向上 可⽤性 (Availability) - ダウンタイムの最⼩化 - パフォーマンス低下の事前検知と対応 保守性 (Serviceability) - トラブルシューティングの効率化 - 予防的なメンテナンスの実現 IBUFOBJOUFSO !!
56. モニタリングとアラート導⼊による期待効果 2/2 RASIS要素 期待効果 完全性 (Integrity) - データの整合性チェックの⾃ 動化 - 異常なデータ操作の検知 セキュリティ (Security) - セキュリティ侵害の早期検知 - 異常なアクセスパターンの識別 IBUFOBJOUFSO !"
57. ϞχλϦϯά • システムやアプリの状態を継続観察しデータ収集 • 対象：CPU、メモリ、ディスク、ネットワーク、アプリの応答 時間など • リアルタイムと履歴データの管理 • ダッシュボードで状態を可視化 IBUFOBJOUFSO !"
58. Ξϥʔτ • 閾値超過や異常検知時に通知 • 通知⽅法：メール、SMS、チャット、専⽤アプリなど • アラートレベルの設定（情報、警告、重⼤など） • エスカレーションルールの設定（対応がない場合の上位通知） IBUFOBJOUFSO !"
59. ओͳར఺ • 問題の早期発⾒と対応 • システムパフォーマンスの最適化 • ⻑期的なトレンド分析でリソース管理 • インシデント対応時間の短縮 • コンプライアンス要件対応 IBUFOBJOUFSO !"
60. ࣮૷࣌ͷ஫ҙ఺ • 適切な閾値設定（誤検知や⾒逃し防⽌） • アラートの優先順位付け • モニタリングシステム⾃体の冗⻑化 • データ保持期間とストレージ管理 IBUFOBJOUFSO !"
61. ࢀߟ: Mackerel • ⾼機能な監視システムをSaaSで⼿軽に試す事ができる ؂ࢹΛҭͯΔɺMackerel • https://ja.mackerel.io/ IBUFOBJOUFSO !"
62. ࢀߟ: ΦϒβʔόϏϦςΟ この講義では取り扱いませんが、オブザーバビリティ（可観測 性）の概念が近年は注⽬されています IBUFOBJOUFSO !"
63. ࢀߟ: ΦϒβʔόϏϦςΟ • 現在では管理対象のシステムが限りなく複雑化したにもかかわら ず、今も多くのエンジニアリングチームが、数⼗年前に開発され た初期のモニタリングツールによるデバッグ⼿法を使っていま す。深く隠されてつかみどころがない問題を迅速に発⾒したい場 ⾯に、従来のツールやデバッグ⼿法ではどう考えても対処できな くなったため、必要性に迫られてオブザーバビリティツールが誕 ⽣しました。 -- 書籍「オブザーバビリティ‧エンジニアリング」1章より IBUFOBJOUFSO !"
64. ࢀߟ: ϝτϦΫεɺϩάɺτϨʔεΛ͏·͘࢖͍෼͚ͯՄ؍ଌੑΛߴΊΑ͏ʂ(id:masayoshi) • https://speakerdeck.com/masayoshi/metorikusu-rogu- toresuwoumakushi-ifen-keteke-guan-ce-xing-wogao-meyou IBUFOBJOUFSO !"
65. ࢀߟ: ৴པੑ͸Ϣʔβ͕ܾΊΔ΋ͷ • 「監視が信頼性を決めるのではなく、ユーザが決めるものだ」 • 可⽤性は信頼性の主要な要素かもしれないが、イコールではな い -- SREサイトリライアビリティエンジニアリングが”ザック リ”「すっきり」分かる本 からの引⽤ IBUFOBJOUFSO !"
66. ࢀߟ: SRE(Site Reliability Engineering)ʹ͍ͭͯ • サイト‧リライアビリティ‧エンジニアリング（英：Site Reliability Engineering、略： SRE）は、Google社が提唱、実践しているシステム管理とサービス運⽤の⽅法論である。 サイト信頼性エンジニアリングと訳される場合もある。また、サイトリライアビリティエン ジニアリングを担当するエンジニアをサイトリライアビリティエンジニア（SRE）と呼ぶ。 • SREは、主に ⾃動化、モニタリング、インシデント管理、キャパシティプランニング、パフ ォーマンス最適化など信頼性向上に向けた改善を継続的に⾏い、速度と信頼性のバランスを 取ることに注⼒します。 • システムが常に利⽤可能であるだけでなく、期待通りに機能し、ユーザーの信頼に応えられ るよう努め、複雑化するインフラを効果的に運⽤し、ビジネスの成功を技術⾯からサポート します。 IBUFOBJOUFSO !!
67. Google - Site Reliability Engineering • https://sre.google/ Hatena Developer Blogɹ͸ͯͳͷαΠτ৴པੑΤϯδχΞϦϯάʢSREʣ • https://developer.hatenastaff.com/archive/category/SRE IBUFOBJOUFSO !"
68. ·ͱΊ • インフラの概観 • RASIS • ⾼可⽤に向けたアプローチ • サービス初期のインフラ • ⾼可⽤を獲得したインフラの例 • モニタリングとアラート についてお話しました IBUFOBJOUFSO !"