1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@issy929

さくらのクラウド検定アドバンスド──(07)デザインパターン

1
Posted at

「さくらのクラウド」を勉強するためのアウトプットを目的に、ドキュメントなどを参照し作成しておりますが、記載の誤りなどが含まれる場合がございます。
最新の情報については、公式ドキュメントをご参照ください。

さくらのクラウド検定アドバンスド試験
https://www.sakura.ad.jp/certification/advanced/

このページのデザインパターンは随時追加します！

代表的なデザインパターン

  • 可用性・拡張性を高める構成
    • ロードバランサアプライアンスを使った高可用性構成
    • エンハンスドロードバランサまたはマーケットプレイスのネットワークサービス
  • コストパフォーマンスを意識した構成
    • 画像などの静的ファイルは「さくらのウェブアクセラレータ」
    • バックエンドにはオブジェクトストレージ
  • DR(Disaster Recoery)を実現する構成
    • GSLBを活用し、メインサイト障害時にDRサイトへ切り替え
      • DR戦略
        • マルチサイト
          • メインと同じインフラ構成
        • ウォームスタンバイ
          • 少ないキャパシティで稼働
        • パイロットライト
          • 最低限のインフラのみ稼働（DBや重要なものだけ）
        • バックアップリストア
          • 定期的なバックアップを使いリストアで復旧
  • インターネットVPNを使用したユーザー拠点との接続
    • VPNルータと拠点側VPNルータを接続
    • VPNルータをマーケットプレイスのネットワークサービスを利用
  • さくらインターネットのサービスでハイブリッド構成
    • さくらのクラウド + さくらの専用サーバPHY
      • 専用サーバPHYではバックアップサービスがない
      • マーケットプレイスのバックアップサービスを利用

構成例

マニュアルにも構成例はあるが、構成例1～5まで。
https://manual.sakura.ad.jp/cloud/design-pattern/example.html

公式には10パターンの構成例が紹介されています。

1. 共有セグメントにサーバーを配置したベーシックな構成

構成例ページ | マニュアル

examle-01

  • 初期投資を抑えてサービスを開始したい・まずクラウドを試したい場合の入門構成
  • 静的コンテンツを提供するWebサーバー・ファイルサーバーに向く構成
  • 共有セグメントにサーバを配置してネットワーク追加費用をゼロ
  • DNSサーバアプライアンスによるDNSラウンドロビンの単純な負荷分散方式
    • example.com. A 203.0.113.77
    • サーバの追加削除でメンテナンスが必要
    • 単純な分散なのでサーバが稼働していないとエラー
  • 今後、ロードバランサ（L4）／GSLB（DNS）／エンハンスドロードバランサ（L7）を追加できる
  • スケールアウトとスケールアップは、1台目のサーバをアーカイブにコピーすることで複製する
    • 別のゾーンで起動させるには、アーカイブをゾーン転送間機能を使う
  • 参考記事：冗長化構成を考える（１）|WEBサーバの冗長化構成 – ロードバランシング

2. 複数のリージョンを使った冗長構成

構成例ページ | マニュアル

examle-02

  • 石狩と東京リージョンの冗長構成
  • GSLB（広域負荷分散）がヘルスチェックを行い、障害リージョンを自動除外 → 低コストDR対応
  • ゾーン間のプライベート通信にはブリッジ接続（L2）×1 とスイッチ×2
  • DBサーバー間のレプリケーションはブリッジ接続（リージョン間L2）経由

3. 負荷に応じてサーバーが増減するオートスケール構成

構成例ページ | マニュアル

examle-03

4. 大量のアクセスを高速処理するWebサイト構成

構成例ページ | マニュアル

examle-04

  • さくらのウェブアクセラレータを使用した構成
  • キャッシュサーバーにより突発的なアクセス増に対応
  • オリジンサーバーがダウンしてもキャッシュから配信継続できるため、可用性向上にも寄与

5. クラウドと専用サーバのハイブリッド構成

構成例ページ | マニュアル

examle-05

  • フロント（Webサーバー）はクラウドでオンデマンドにスケールアウト
  • バックエンド（DBサーバー）は専用サーバで高速ディスクI/O・安定性能を確保
  • DB負荷が高く、スケールアウト可能なWebフロントと高性能DBを組み合わせたい場合
  • クラウドと専用サーバの役割分担の思想を明示：フロントエンドはクラウドの柔軟性、バックエンドは専用サーバの安定性能

6. サーバーメンテナンスを配慮したセキュアな環境構成

構成例ページ

examle-06

  • VPNルータにより管理者・開発者のみがVPN経由でDBや内部サーバーにアクセス可能
  • DBはプライベートネットワーク（スイッチ）経由のみアクセス。インターネット直接露出なし
  • DBアプライアンスの冗長化はオプション機能で追加可能

7. ファイルサーバーをクラウド環境にする最小構成

構成例ページ

examle-07

  • オンプレミスのファイルサーバーをクラウドに移行するための最小構成
  • VPNルータで社内ルータとVPN接続することで、社内LANと同等のファイルアクセス環境を実現

8. 社内システムにVPNで繋ぐ安全なサーバー構成

構成例ページ

examle-08

  • 業務システムゾーン（東京）と監視・運用ゾーン（石狩）を別リージョンに分離
  • ブリッジ接続でリージョン間を接続し、業務システムを別拠点から監視
  • VPN接続により従業員が社外から安全にアクセス可能

9. シンプルなバックアップの構成

構成例ページ

examle-09

  • 週次・世代間バックアップを低コストで簡単に実現したい場合。ファイル単位での復元は不要な場合
  • ディスク単位のフルバックアップをアーカイブとして保存
  • 注意: バックアップはディスク単位のため、ファイル単位の選択的リストアには対応しない

10. 高機能なバックアップの構成

構成例ページ

examle-10

  • ファイル単位での選択的リストアが必要・差分/増分バックアップでストレージコストを抑えたい・バックアップデータを自社管理ストレージに保管したい場合
  • バックアップ種別： フルバックアップ・差分バックアップ・増分バックアップの3種に対応
  • Acronis Hosted: Acronis管理のクラウドストレージへバックアップ。インフラ管理不要
  • Acronis VM/Server ワークロード： 自社管理のストレージサーバー（NFS/SMB等）にバックアップデータを保管
  • バックアップ種別： フルバックアップ・差分バックアップ・増分バックアップの3種に対応
  • バックアップ対象： サーバー単位・ディスク単位・ファイル単位の3粒度に対応（構成例9より高機能）
  • 時間指定スケジュールが可能
  • Acronis Advanced Pack オプションでセキュリティ機能・管理機能を追加可能
  • Workloadプランは自社ストレージを使うため、Hostedより初期コストは高いが長期的に安くなる可能性あり

独自検討構成例

独自構成例A: 3層アーキテクチャ（React + SpringBoot + DB）

前提・要件

  • フロントエンド: React（SPAとしてビルドした静的ファイル）
  • APIサーバー: SpringBoot（コンテナ化）
  • データベース: RDB（PostgreSQL or MariaDB）
  • セキュリティ: APIサーバー↔DB間はプライベートネットワーク経由必須
パターンA-1: 推奨構成（AppRun専有型 + DBアプライアンス）

webapp-01

使用サービス

サービス 役割
ウェブアクセラレータ React静的ファイルのCDN配信・オリジン負荷軽減
AppRun専有型（ロードバランサ） SpringBootコンテナへのリクエスト分散
AppRun専有型（ワーカーノード） SpringBootコンテナ実行・オートスケール
コンテナレジストリ SpringBootコンテナイメージの保管
スイッチ AppRun専有型↔DBアプライアンス間のプライベートネットワーク
DBアプライアンス（冗長化オプションあり） PostgreSQL or MariaDB。障害時に数秒で自動フェイルオーバー

設計ポイント

  • AppRun専有型を選択することでスイッチ接続が可能になり、SpringBoot→DBの通信をプライベートネットワーク内に閉じられる
  • Reactはビルド済み静的ファイルをCDN（ウェブアクセラレータ）で配信することでオリジンサーバーの負荷をゼロに近づける
  • AppRun専有型のオートスケールでAPIサーバーの負荷増加に自動対応
パターンA-2: シンプル構成（仮想サーバーのみ）

webapp-02

使用サービス

サービス 役割
エンハンスドロードバランサ フロントサーバーへのリクエスト分散
仮想サーバー（フロント） nginx + Reactビルド成果物配信 + SpringBootへのリバースプロキシ
仮想サーバー（API） SpringBoot実行
スイッチ フロント↔API↔DB間のプライベートネットワーク
DBアプライアンス PostgreSQL or MariaDB

設計ポイント

  • 全層がスイッチ経由のプライベートネットワーク内に収まりセキュア
  • インフラ管理はすべて手動（OSパッチ、JVM管理、デプロイ作業）
  • オートスケールは自前実装が必要

参考

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?