システム設計勉強会2回

システム設計勉強会2回

Transcript

1. システム設計 勉強会第二回
2. オンプレとクラウドの本質的な違い 世の中に存在するシステムは、「オンプレ」か「クラウド」のどちらかで稼働しています。 両者には違いこそありますが本質的には、 • オンプレは「所有」 - 設備や機材を自前で用意し、設置して利用する • クラウドは「利用」 - SaaS, PaaS, IaaSとして提供されるものを利用する 2010年前半まではオンプレが主流でしたが、現在ではクラウド /ハイブリッドが主流です。
3. オンプレからクラウド移行が増加する理由 • オンプレは設備を自社所有するため設備を設置するスペースが必要となる。 • 処理能力の要となるCPUは後から変更できない、追加費用で買い直しとなる。 • トラフィックの増加に対応しづらい、スケーラビリティが限定的である。 • ネットワークも物理設備が必要であるため、ネットワーク機器の専門知識が必要となる。 (CCNAなど) • 物理的な故障が発生した際には、機器の交換が必要となる。 • 物理設備のメンテナンス、監視要員が 24/7で必要となる。 • 設備調達に数千万円/億円単位での投資が必要となる。 • 非機能要件を物理設備の設計に落とし込む難易度と専門知識の複雑さ。 オンプレでは上記の課題があり、これらを解決するためにクラウドが普及した。
4. オンプレからクラウド移行が増加する理由 オンプレ クラウド 初期コスト 極めて高い(数千万円↑) 0円(Pay-as-You-Go) スケーラビリティ 手動・物理的制約 自動・論理的拡張 調達速度 遅い(設置まで含むと数週間 ) 速い(数分-数時間) 障害対応 自前・フルスタック サービス依存・抽象化 (責任 共有モデルに基づく )
5. オンプレからクラウド移行が増加する理由（追記） 冗長化に対して莫大な費用を要する • サーバーをスケーラビリティ +冗長化で考えると数十台 - 数百台単位で調達が必要 • 1台のサーバーにつき電源モジュール複数系統 • 設備を設置する施設に対して、変電所から異なる電源を複数系統引き込む • 非機能要件によっては発電設備や UPSの設置が必要となる • ネットワークも物理ルートの異なる複数回線の引き込み SPOF(単一障害点)の排除、SLAを90% ⇨ 99% ⇨ 99.9% ⇨ 99.99%と高めるたびに指数関数的に費用が増加す る。
6. クラウド設計とは？ 「動くものを作る」から「変化に強い仕組みを作る」へ。 • 設計の目的の変化 ◦ 従来（オンプレミス）：ピーク時に耐えられる「最大サイズ」を固定で設計する。 ◦ クラウド：需要に合わせて「伸び縮み」し、失敗しても「すぐにやり直せる」設計。 • Design for Failure（壊れることを前提に設計する） ◦ 「サーバーはいつか必ず壊れる」と考え、 1台が死んでもサービスを止めない（冗長化）仕組みを最 初から組み込む。 • 疎結合（Loose Coupling） ◦ 各機能（DB、認証、アプリ）をバラバラに独立させ、一部の変更が全体に影響しないように作る。
7. クラウド設計の 5大原則 Well-Architected フレームワークの視点。 • 設計時に常に自問自答すべき 5つの柱 柱 ポイント 運用性 手作業を減らし、コードでインフラを管理する (IaC) セキュリティ 全レイヤーで防御し、権限は「最小限」だけ与える 信頼性 障害からの自動復旧と、データの多重化 パフォーマンス マネージドサービスを使い、負荷に応じて自動拡張する コスト最適化 不要なリソースを止め、使った分だけ払う仕組み
8. クラウドネイティブな設計への進化 「サーバー」を意識しない設計（ Serverless & Managed） • 抽象化のステップ ◦ レベル1： 物理サーバーを仮想サーバー（ EC2等）に置き換える。 ◦ レベル2： データベースやキャッシュをマネージド（ RDS等）にする。 ◦ レベル3： サーバーの存在すら意識しない「サーバーレス（ Lambda等）」を主軸にする。 • 設計者の役割の変化 ◦ 「メモリやディスクの計算」に時間を割くのではなく、「 どのサービスとどのサービスを繋げば、最速 でビジネス価値が出せるか」 というサービスの組み合わせ（ オーケストレーション）が設計の主戦 場になる。
9. マネージドサービスとは？ インフラ管理を「所有」から「利用」へ。ビジネス価値への集中を実現する仕組み。 • クラウドベンダーがインフラの構築・運用・保守を「肩代わり」してくれるサービス。利用者は「 サーバーの お世話」ではなく「アプリの開発」だけに専念できる。 セルフマネージド • 利用者がやること： OSパッチ、バックアップ、冗長化、セキュリティ更新、ハード故障対応、キャパシティ 設計（＝膨大な「作業」） マネージドサービス • 利用者がやること： データ投入、コード実行、設定の最適化（＝ 「価値創出」） • ベンダーがやること： 上記の「作業」すべてを自動化・代行
10. マネージドサービスの価値 「守り」の自動化と「攻め」の高速化。 メリット スピード 数クリック、数分でエンタープライズ級の環境が整う。 信頼性 自動バックアップ、マルチAZ（多拠点）配置による高可用性の標準化。 スケーラビリティ アクセス増に応じて自動で拡張（オートスケール）。予測困難なビジネスに対 応。 コスト最適化 使った分だけの従量課金。
11. マネージドサービスの思想 「餅は餅屋へ」。付加価値を生まない作業からの脱却。 • Undifferentiated Heavy Lifting（差別化につながらない重労働）の排除 • 設備の調達やメンテ、物理障害への対応はビジネスの成功に直接は貢献しない。 • これらをクラウドベンダー（プロ）に丸投げし、自社のリソースを「独自の価値（アプリケーション開 発）」に集中させる。 • 責任共有モデルの理解 • インフラの可用性やセキュリティの「土台」はベンダーが保証。 • ユーザーは「その上のデータと設定」にだけ責任を持つ。
12. 責任共有モデルとは？ 「どこまでがクラウド側の責任で、どこからが自分の責任か」を明確にするルール。 • 責任共有モデルの本質 ◦ クラウドを利用しても、セキュリティの責任がすべてベンダーに移るわけではない。 ◦ ベンダーは「クラウドのセキュリティ（インフラ）」に責任を持つ。 ◦ 利用者は「クラウド内でのセキュリティ（データや設定）」に責任を持つ。 • なぜこれが必要か？ ◦ 責任の所在を曖昧にすると、パッチ当ての漏れや設定ミスによる情報漏洩が発生するため。
13. 責任の境界線 「物理」はベンダー、「データ」は自分。 担当箇所 ベンダー責任 ユーザー責任 インフラ データセンターの物理的保護、サーバー の故障交換 (責任なし) ネットワーク 物理ネットワークの維持、仮想化基盤の防 御 ファイアウォールの設定、通信の暗号化 OS・ソフト マネージドサービスの場合のパッチ当て 仮想サーバー（EC2等）のOSアップデート データ 責任なし データの暗号化、バックアップ、権限管理
14. 責任の境界線
15. サービス形態による責任範囲の変化 マネージドサービスを使うほど、ユーザーの「責任（苦労）」は減る。 • オンプレミス： すべてが自分の責任（空調からアプリまで）。 • IaaS (仮想サーバー)： OSから上は自分の責任。自由度は高いが負担も大きい。 • PaaS / マネージドサービス： OSやミドルウェアの責任もベンダーへ移譲。利用者は「コードと設定」だけ に集中。 • SaaS： ほぼすべての責任をベンダーが負う。利用者は「 IDとデータ」を管理するだけ。 結論： 「ビジネスに集中したいなら、責任範囲をベンダーに押し付けられる（＝マネージドサービスを 活用する）設計を目指すべき」という思想に繋がります。
16. クラウドへの移行パターン（ 6R） 移行の目的と6つの選択肢 クラウド移行は、単にサーバーを移すことではなく、ビジネスの目的（コスト削減、スピード向上、拡張性など）に 合わせて最適な手法を選択するプロセス。 • 移行の全体像： ◦ Rehost (リホスト): そのまま移す。 ◦ Replatform (リプラットフォーム): 少し最適化して移す。 ◦ Refactor (リファクター): 抜本的に作り直す。 ◦ Repurchase (リパーチェス): 既製品に買い替える。 ◦ Retain (リテイン): 現状維持。 ◦ Retire (リタイア): 廃止する。
17. クラウドへの移行パターン（ 6R）
18. Rehost 「そのまま」持っていく：最短・最速のクラウド化 • 定義： 現行のシステム（OSやアプリ）を構成変更せず、そのままクラウド環境（ EC2等）へ移設する。 • メリット： ◦ 移行スピードが最も速く、リスクが低い。 ◦ データセンターの撤去期限がある場合などに最適。 • 使い所： 複雑すぎて中身をいじれないレガシーシステムや、まずはクラウドに乗せてから最適化したい場 合。
19. Replatform 「少しだけ」変える：コアを変えずに恩恵を受ける • 定義： アプリの根幹は変えず、DBなどをマネージドサービス（ RDS等）に置き換える。 • メリット： ◦ OSやDBのパッチ当て、バックアップ運用から解放される。 ◦ アプリの改修を最小限に抑えつつ、クラウドの運用メリットを享受できる。 • 使い所： 運用の手間を減らしたいが、アプリを大規模改修する予算や時間がない場合。
20. Refactor/Re-architect 「作り変える」：クラウドネイティブの真髄 • 定義： クラウドの機能をフル活用するため、アプリの構造（マイクロサービス化やサーバーレス化）を抜本 的に見直す。 • メリット： ◦ スケーラビリティ、耐障害性、コスト効率が最大化される。 ◦ ビジネスの変化に極めて強い基盤になる。 • 使い所： 今後も継続的に機能追加が必要な、自社の競争力の源泉となる戦略的システム。
21. Repurchase 「買い替える」：所有から利用への完全転換 • 定義： 既存のソフトウェアを捨て、 SaaS（Salesforce, Microsoft 365など）へ乗り換える。 • メリット： ◦ サーバー管理、アプリ開発そのものが不要になる。 ◦ 常に最新の機能が提供される。 • 使い所： 会計、人事、メールなど、自社で独自開発する必要がない「非競争領域」の業務システム。
22. Retire 「捨てる」：資産の整理整頓 • 定義： 移行のタイミングで、利用率が低いシステムや不要になった機能を廃止する。 • メリット： ◦ 移行コストと、将来の運用保守コストをゼロにできる。 ◦ IT資産のブラックボックス化を防ぐ。 • 使い所： 数ヶ月間アクセスがないシステム、代替手段がすでにある古いツール。
23. Retain 「維持する」：あえて動かさない勇気 • 定義： 調査の結果、現時点ではクラウドへ移行せず、オンプレミスに継続して残す。 • メリット： ◦ 不必要な移行コストやリスクを回避できる。 • 使い所： 減価償却が終わっていないハードウェア、特殊な周辺機器との接続が必要なもの、法規制で データ持ち出しができないもの。