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

インフラ殴り込み入門_vol1

 インフラ殴り込み入門_vol1

y.ashida

July 18, 2020
Tweet

Other Decks in Programming

Transcript

  1. 講義の流れ  自己紹介  講義の目的  インフラ構築の全体像  インフラ構築の要件定義とは 

    各項目の要件定義と設計  実際のプロジェクトでは、、 書籍「インフラ設計のセオリー(※) 」の内容に沿って、 要点を絞ってインフラ構築の基礎を解説。 (※) 著:JIEC基盤エンジニアリング事業部インフラ設計研究チーム
  2. 講師について 芦田 祐希 株式会社たたかうWEB代表 (代表しかいない) •経歴  29歳まで職場を転々、フリーター。人生崖っぷちの危機感からプログラミングを勉強。  30歳は会社員SEとして経験を積んだが、あまりの給料の安さにフリーランスへ転身。

     2018年33歳の時に勢いだけで株式会社たたかうWEBを創立。  現在は受託開発をしつつ人材・教育の分野に力を入れている。 •やってる仕事  システム受託開発(ディレクター・実装) 自身の得意分野はWEBアプリ(Django)  SES事業(トラブルで振り出しに)  プログラミングスクール(構築中)
  3. インフラ構築全体像 フォーターフォールを想定。  要件定義  設計  実装  試験

     運用・保守 インフラ構築もアプリ開発と同じフロー。
  4. 機能要件・非機能要件 インフラの要件定義とは、顧客要求から非機能要件を定義すること。 機能要件 → 業務上の要件 → 開発チーム担当 「店舗からの売上データ(CSV)を管理画面で集計する。」 「決済代行会社と連携してWEBサイトに決済システムを導入する。」 ※業務を動かすための機能の定義。

    非機能要件 → システム上の要件 → インフラチーム担当 「障害発生時は、3時間以内にバックアップデータからシステムを復旧する。」 「将来、ユーザーの増加に備えて性能拡張が可能な構成とする。」 ※業務の安定稼働を目的としたシステム性能の定義。
  5. 非機能要件の分類 インフラ要件は6つのカテゴリーに分類できる。 • 可用性 システムの信頼性・安定性。どれだけ安定して稼働するか。「現在」に対する備え。 • 性能・拡張性 システムの処理性能。将来スペックの拡張がしやすいか。「将来」に対する備え。 • 運用・保守性

    システムの安定稼働を目的とした運用。どのレベルで保守を行うか。 • 移行性 現行システムを開発システムに移行する際の要件。 (本講では割愛) • セキュリティ システムの安全対策などの要件。 • 環境・エコロジー システム環境の耐震、温度、騒音。地球に優しいシステムかどうか。(本講では割愛)
  6. 継続性 継続性・・・ サービスがどれだけ中断せず継続して稼働するか。 →稼働率を定義する。 稼働率 = (サービスが実際に利用できた時間) ➗ (サービスを提供すべき時間) 例)

    ・年間に5分のサービス停止のみ許容する場合 稼働率 = (8760 - 0.08) / 8760 x 100 = 99.999% ・平日8時間のサービス稼働、月間1時間のサービス停止を許容する場合 稼働率 = (1920 - 12) / 1920 x 100 = 99.4% 稼働率要求を満たすような冗長化の設計。 クラウドサービスの場合、稼働率要求を満たすようなサービスを選定。(SLA参考)
  7. 回復性 回復性・・・ システムがどこまで回復できるのか。 ・目標復旧時点(Recovery Point Objective) どの地点までデータを担保するか。 ・目標復旧時間(Recovery Time Objective)

    復旧時間をどこまで許容するか。 正常稼働 障 害 復旧作業 RTO 正常稼働 RPO RPOおよびRTOを元に回復手段と 回復までの代替え運用方法を定義。
  8. SPOFの排除 ネットワーク ルーター #1 スイッチング・ハブ #1 負荷分散装置 (稼働系) WEBサーバー #1

    ルーター #2 スイッチング・ハブ #2 負荷分散装置 (待機系) WEBサーバー #2 どこか1つが故障してもサービスは停止しない。 →可用性の向上 冗長化を行う。 冗長化とはシステムを構成している要素を多重化すること。
  9. 並列クラスタ 同じ性能のサーバーを複数並列稼働させる。 ネットワーク 負荷分散装置 HTTP サーバー JavaEE サーバー サーバー#1 HTTP

    サーバー JavaEE サーバー サーバー#2 HTTP サーバー JavaEE サーバー サーバー#3 メリット ・クラスタメンバに障害があってもサービスが停止しない。 ・負荷分散。 デメリット ・一意性と順序性が担保できない。 WEBサーバーの冗長化に適したクラスタリング。
  10. HA (High Availability)クラスタ 同じ性能のサーバーを複数台用意し、稼働系と待機系に分ける。 アプリケーション メリット ・稼働系に障害があっても待機系に切り替えるので サービスが止まらない。 ・一意性・順序性を担保できる。 ・障害時はサービスIPの切り替えのため、アプリケー

    ション側から稼働系サーバーを意識する必要がない。 デメリット ・負荷分散はできないなど性能面で劣る。 DB・メッセージングサーバーの冗長化に適したクラスタリング。 サーバー#1 稼働系 OS HAクラスタ 製品 DBMS サービス IP サーバー#2 待機系 OS HAクラスタ 製品 DBMS 共用 ディスク
  11. 可用性 まとめ •要件定義 稼働率 冗長化 バックアップ •設計 単一障害点(SPOF)を潰す。 冗長化 ハードウェア:

    電源ユニット・ネットワークアダプタ・ストレージ(RAID) サーバー: 並列クラスタ: WEBサーバー HAクラスタ: DBサーバー・メッセージングサーバー
  12. 拡張例:レスポンスの悪化 ・CPU・メモリがボトルネックの場合 まずはスケールアップで対応。 上限値でも解決しない場合はスケールアウト。 ・ヒープサイズに問題がある場合 ヒープサイズ拡張。 ただし、 OSの使用メモリ + ヒープサイズ

    < 物理メモリ となること。 逆転するとOSのページング(スワップアウトの1種)が生じ、処理速度低下。 ・データキャッシュ率が低下している場合 データキャッシュ領域の拡張。ただし、上記のように限界値に注意。 ・ネットワーク転送速度の問題の場合 帯域の拡張検討。
  13. バックアップ 問題発生時の保険。極めて重要。 ・どのデータを ・どの頻度で ・どの世代まで ・どれぐらいの間 バックアップするか。 手厚くするほどコストが増大。 頻度を強化 →

    サーバーの処理コスト&データ量増大 世代・保管期間を強化 → データ量増大 ※正常時ログと障害時ログを比較したりするので、 ログは最低1ヶ月、できれば3ヶ月は保持したい。
  14. 運用・保守性 まとめ •要件定義 ・運用時間 ・バックアップ運用 ・監視運用 •設計 まず運用時間の設計 そして ・バックアップ設計

    頻度・世代・保管期間 ・監視設計 プロセス・メッセージ・リソース・ハードウェア・ジョブ 運用の自動化