昔どこかの採用プロセスでプレゼン試験用に作った資料です。

1. AWSを利用した
A社システムの提案
2015.3.23 Tomohiro Amemori
1

2. 目次
A社システムの現行システム要件
構成図、満たす項目、課題
A社システムの新システム案（AWS）
構成図、満たす項目、AWS向上点
A社システムへのその他適用
2

3. A社システムの切り替えシナリオ
A社システムの移行には、以下のような経緯があります。
既製製品である社内チケット管理システムのダウンロード版を購入し、オンプレミス上に展開、社内独自の仕様にカスタマイズ
して利用しています。既存の課題解決のため、AWSへの移行が決定しています。
なお前提として、IT部門ではAWSのサービスは把握済で、構築の実績がないためその情報検証を確認します。
3

4. 既製製品の費用比較と機能比較
ダウンロード版、SaaS版の２種類があります。オンプレミスに置く場合、AWSに置く場合、計３パターンについて、それぞれ
メリット・デメリットが示されます。★印は優勢であることを示し多いほど良いと判断します。この結果からAWSへの移行が決
定されます。
4
オンプレミス版 AWS版 SaaS版
費用(初期) パッケージ＋サーバ ★パッケージのみ ★なし
費用(固定) DC利用料(月額固定) ★AWS利用料(従量課金) SaaS利用料(月額固定)
機能 ★カスタマイズ可能 ★カスタマイズ可能 カスタマイズ不可

5. A社システムの業務要件
A社でシステム変更しようとしているシステムは、以下のように運営されています。
業務フロー：世界中にいるエンジニアがIssueを作成し解決すればクローズします。ファイル添付も可能です。社内からのアクセ
スのみを許可しています。ADFS連携で認証しています。
5
チケット管理システム
シングルサイ
ンオン
ADFS連携
Issue作成/回
答/クローズ
資料添付 拠点接続
社内接続の
み可
管理は特定
端末のみ

6. A社システムの機能要件
現行システムの特徴： 早朝のみスパイク発生。世界中からのアクセスがあるが現在は日本に配置。５年で減価償却する予定で見
積もられたファイルサイズ。
6
リクエスト量（ピークあり）
デイリーで100チケット、1チケットあたり5トランザクション
ピークは朝1時間で全体の8割（残り業務時間のトランザクションと
同等）
ファイルサイズ (多い)
1チケットあたり平均10MBの添付ファイル
デイリーで1GB、1年で365GB、5年で1.8TB

7. A社システムの非機能要件
現行システムの、可用性、性能、保守性、移行性、セキュリティは、以下のとおり。
7
可用性 サービスSLAとして、業務時間無停止、月１回程度のメンテ停止可能、正月は
サポートしない。データは定期的にバックアップしていつでも復旧可能。
性能 現状のリクエスト数、トランザクション数、累積のファイルサイズを許容できている
。
朝のスパイク時のみ性能が下がる。
保守性 手動コピー構築。手動ネットワーク設定。手動アプリインストール。手動DB構築。
移行性 データは手動Import/Export。ソースはパッケージをリポジトリ管理と手動
Deploy。ファイルはNFSにて管理（バックアップ、テープバックアップもある）。
セキュリティ 各サーバはID/PWを定期管理。アクセス制御はDCへのアクセス制御と各サーバ
へのアクセス制御。管理は特定端末からのみ(踏み台)。

8. corporate data center
A社現行システム構成（図）
LB
corporate data center上にあるSystemに世界中の各拠点ネットワークから専用線またはVPNでPrivate接続
ADFS
NFS
8
Tokyo, Japan
Mumbai, India
San Francisco, US
(ロードバランサ : A社所有の仕組み)
WEBサーバ：3台 (最小冗長化構成)
DBサーバ：2台 (Master : 1台／Slave :
1台)
Storage (NFS) : 1.8TB (1GB/日☓365
日☓5年）
BackupStorage : 10TB (5世代)
(テープBackup : A社所有の仕組み)
サーバにはは踏み台サーバからのみア
クセス可能でアクセス履歴を証跡化
(図ではMumbaiからメンテンナス)

9. なぜAWSなのか
まずは、AWSのを利用するための６つのメリットを確認します (早い、安い、リスク小さい、グローバル)。
変動費性・・・初期費用なしで使った分だけ支払えばよい。
スケール簡単・・・すぐ増やせて、すぐ落とせる。朝とか。費用も月額課金。
見積もり不要・・・一度増やしても、不要なら消せる。バックアップしすぎても安心。
検証不要・・・大丈夫かどうか判断しながら進められる。スピード感とともに開発ローンチ。
固定設備不要・・・初期設備費不要。BCPも簡単。
たくさんのリージョン・・・BCP簡単。ブローバルなレイテンシー問題にも対応可能。
9

10. AWSで注意すべき点
AWSにも考慮したシステムを設計しなければならないことがあります。デメリットを明示してみます。
AWSの独自メンテナンスはゼロではありません。例) 2014年秋のEC2大量再起動
社外でない場所にあります。ITコンプライアンス的に問題がないことが必要です。
コンソールにログインできるとなんでもできます。Credentialや暗号化キーも人的な悪意にさらされます。
いままで既存DCにあることで発生していなかったアクセス制御は自分で行う必要があります。
システムとしてはAWSの停止に依存しない、ヒューマン脆弱性の影響を最小限にした、ITコンプライアンスに準拠できる仕組み(
監査証跡や法的資格など)が重要です。および、システム脆弱性を出さないための監査をしっかり行うことも必要となります。
10

11. 新システムの非機能要件
新システム(AWS)での、可用性、性能、保守性、移行性、セキュリティは、以下のような対策で満たされます (★印はAWSので
可能となる機能です)
11
可用性 サービスSLAは現行同様。AWSでは各サービスにもSLAが定義されている
（EC2:99.95%、S3:99.9%、RDS:99.5%）。Snapshot機能によりデータの定期バ
ックアップも行う。★複数Regionを利用したBCPも行う。
性能 ★スケールアウト、スケールアップによって、スパイクに対応可能となった。性能改
善も任意に行える。ただしDBのスケールアップにはDBリブートが必要。
保守性 AMI化したイメージより複製可能。APIによって外部から容易にスケール可能。
DB、ロードバランサもAPIによる操作可能。
移行性 データ、ソース、ファイルはS3やEBSなど永続化されたStorage経由でのImport
／Export、Deployが可能。EBSはマルチリージョンコピー可能のためBCPのため
のデータ同期も簡単。★暫定的に利用できるため不要になれば費用発生しない。
セキュリティ VPC、サーバ、へのセキュリティグループ設定。Credentialによるサーバアクス
制御。IAMロールによるコンソール操作権限も設定。管理は特定端末のみ(踏み
台)。★コンプライアンス対応としてはPCI DSSも取得済(AWSは金融にも実績あ
り)。

12. 新システム構成（図）
Tokyo, Japan
AWS上にあるSystemに世界中の各拠点ネットワークから専用線またはVPNでPrivate接続
ADFS
12
Mumbai, India
San Francisco, US
corporate data center
ロードバランサ：ELB
WEBサーバ：EC2 x 3台以上 (Scaling
で任意に台数変更)
DBサーバ：RDS (Master:1台＋
Slave:1台＋リードレプリカ:MAX(5台)
(負荷次第で台数変更)
Storage (NFS)：EBSをNFS化、MAX
回数(5回)のSnapShot
BackupStorage：SnapshotをGlacier
に暗号化して保存
認証：自社ADFSで認証
★スパイク対応：APIで任意スケール
VPC, サーバにはは踏み台サーバから
のみアクセス可能でアクセス履歴を証
跡化
(図ではMumbaiからメンテンナス)
コンソールやAPIの操作をCloudTrail
で証跡化
★BCPを考慮してマルチRegion

13. Network & Security
Tokyo, Japan
利用したいサービスは、VPC、EC2、RDS、CloudTrail および IAM、Security Group となります。
13
Mumbai, India
San Francisco, US
• Private接続として接続
VPN ( またはDirect Connect)
• Privateなネットワーク定義
• Security Groupでアクセス制御
VPC
• Security Groupでアクセス制御
• IAMによる管理者のみ操作
• http/https以外は直接アクセス不可
(踏み台サーバのみターミナル接続許可)
EC2 (Webサーバ、踏み台サーバ)
• Security Groupにてアクセス制御
RDS
• AWSへのAPI操作を証跡化
• EC2へのアクセス証跡は踏み台サーバでも取得
CloudTrail
security group
security group
security group

14. Balancing
Tokyo, Japan
利用したいサービスは、VPC、EC2、ELB および、AMI、SDK となります。
14
Mumbai, India
San Francisco, US
•ロードバランシング
•負荷に応じてスケールしたWebサーバをバラン
シング
ELB
•通常3台 (冗長化MIN構成)
•★スパイク時にスケールするようにスケジュー
リング：予想時刻までに自動でN台のサーバを
AMIからコピーし、ELBにてバランシング開始、
不要になったらインスタンスは破棄、通常はス
ケジューリング、※スパイクタイミングは明確な
のでオートスケールは利用しない
EC2 (Webサーバ)
•操作端末からのAPI操作によって臨時スケール
可能
API (SDK)

15. Storage & Backup
利用したいサービスは、EBS、S3、Glacier、RDS となります。
15
•Storage甩EC2でNFS化
•SnapshotをS3に保存 (Max5履歴)
EBS (NFS化)
•Snapshotを暗号化してさらにバックアップ
Glacier (退避)
•Master/Slaveおよびリードレプリカ(Max5
台)、自動フェールオーバー設定
•自動バックアップと自動Snapshotを設定
•S3に作成されるバックアップを暗号化して
Glacierへ退避
RDS (MySQL)
Mumbai, India

16. Migration
利用したいサービスは、VPC、EC2、EBS、RDS、Glacier となります。
16
Mumbai, India
corporate data center
NFS
• 初期構築はゼロから
• BCPは構成管理ツールにて可能
VPC
• 新規サーバ構築はゼロから
• アプリは既製製品のマニュアルに従って手動Deploy
• AMI化しておく
EC2 (Webサーバ)
• 初期データは corporate data center のNFSと AWS上のEBS化間
でファイル転送させる
• EBSから各種サービスへデータをセットアップする
EBS (初期移行データ)
• 初期データはRDBのImport機能にて行う
RDS
• テープは corporate data centerのものなので移行しない
• AWS ダイレクトインポートサービスで直接Glacierへ配置することは
可能
Glacier

17. BCP
Tokyo, Japan
利用したいサービスは、ここまでで予定している全サービス となります。
17
Mumbai, India
San Francisco, US
•同じ構成を別Regionに複製 (EBSとSnapshotからでデータ最新化が可能)
•必要に応じて、外部から起動、破棄 (利用しているRegion障害など)
マルチRegion

18. ADFS
Tokyo, Japan
利用したいサービス は ありません。
ADFS
18
Mumbai, India
San Francisco, US
corporate data center
•既存ADFS認証をそのまま利用
•ADFSの認証情報があればよいのでAWS
独自の構成を考慮する必要なし
•将来的にAWSコンソールもADFS連携する
ADFS

19. 既存システムからの改善点
◎従量課金に変わったこと (使った分だけ支払う)
◎スケールしやすいこと (朝のスパイクに対応できる)
◎バックアップ手段が潤沢（EBSをS3にスナップショット＋Glacierへのバックアップ）
◎セキュリティもコンプライアンス的に上がっている (PCI DSSなど) ※セキュリティ監査は必要
◎BCPも簡単 (不要なら消すことができる)
✕海外からの接続については未対応 (各Region間DB複製の性能検証できていないため)
19

20. その他システムへの適用
１つ事例ができると、後続で移行意欲のあるサービスに対するデザインパターン化ができます。
スケール部分（AMIにして増殖、ELBにてスケール）
セキュリティ・コンプライアンス部分（ログ取得、ACL制御）
バックアップ部分（EBSをNFS代わりに利用、数世代分をS3にバックアップ）
BCPパターン（２Regionで簡単複製）
簡単なパッケージ導入（バランサ、アプリ、DB、DISKの構成）であればCatalog化, Template化して簡単に流用が可能です。
20

21. 他社ベンダーとの比較 (念のため)
社内ノウハウが多い。エンジニアも多い。
豊富なサービス。制約となる仕様が少ない。
21

22. まとめ
A社システムの現行システム要件
構成図、満たす項目、課題
A社システムの新システム案（AWS）
構成図、満たす項目、AWS向上点
A社システムへのその他適用
22

23. Q&A
23