株式会社BFT　部長代理 富岡 秀明（トミオカ ヒデアキ）氏

1. 非機能要求グレードから見る
オンプレとクラウドの違い
株式会社 BFT

2. 相談してくれた人
•性別：男性 年齢：28歳
•職種：エンジニア歴6年（インフラエンジニア歴2年）
•世帯規模：独り暮らし
•勤務地：東京都内
エンジニアになってから、4年間はアプリケーションエンジニアとしてやってきた。
2年くらい前に、エンドユーザにあれこれ注文つけられ都度仕様変更しなくちゃいけ
ない辛さに耐え兼ね、これからはインフラエンジニアだと一年発起して、インフラ部
門へ移った。
新プロジェクトの担当に抜擢されたが、クラウドという響きが大好きなお客様の要望
によりAWSを使うことになったがやった事ないし・・。
さて、どうしよう。システム構成とかサーバ台数とか、オンプレと何が違うのかな。
また、AWSの特徴を生かした構成提案をして良いところも見せたい。
そこで、AWSやってるらしい知り合いのK子さんに相談してみた。

3. オンプレの設計し
かやったことない
ですが僕にもでき
ますか。
大きな違いはなん
ですか？
気を付けるポイン
トは？
AWSでできることできない事を
しっかり把握して、要件定義・
設計を行う事が重要
機能の詳細はGIYF
検索ワード＋BlackBelt
②
③
オンプレの設計ができる人は
AWSでも変わらずできる。①

4. 非機能要求グレードって何者？

5. 視聴履歴からおす
すめ番組をメール
で送信したい
同時配信数が年間
３０％増加しても
性能が変わらない
ようにしてほしい
２４時間３６５日
ノンスストップで
配信できるように
してほしい
キャンペーン時は
通常の１０倍のア
クセス数を処理で
きるようにしてほ
しい
ユーザが過去のTV
番組を自由に検索
できるようしした
い
倍速再生できるよ
うにしたい機
能
要
求
非
機
能
要
求
ユーザに直接
提供する機能
システム基盤
（インフラ）
で担保する機能

6. 非機能要求グレードの中身
可用性
性能・拡張性
運用性
保守性
セキュリティ
システム環境
システムサービスを継続的に
利用可能とするための要求
システムの性能、および将来のシ
ステム拡張に関する要求
システムの運用に関する要求
保守のサービスに関する要求
情報システムの安全性の
確保に関する要求
システムの設備環境や
エコロジーに関する要求
・運用スケジュール（稼働時間・停止予定など）
・障害・災害時における稼働目標
・業務量および今後の増加見積もり
・システムの特性（ピーク時、通常時、縮退時など）
・運用中に求められるシステム稼働レベル
・バックアップや監視の対応レベル
・保守用環境レベルの確認
・利用制限
・不正アクセスの防止
・重量／空間、温度、電力などシステム環境事項
要求の種類 何を決めるか

7. 可用性
可用性
個々の機能（サービス）の可用性は定義されていて変えられない。
その上で、その組み合わせにより設計上はオンプレ以上に可用性を高める事が可能。
ただし、AWSの大規模障害については打つ手が無く壊れた時を考える事自体がナン
センス。
Amazon EC2 サービスレベルアグリーメントhttp://aws.amazon.com/jp/ec2-sla/
Amazon RDS サービスレベルアグリーメントhttp://aws.amazon.com/jp/rds-sla/
Amazon S3 サービスレベルアグリーメントhttp://aws.amazon.com/jp/s3-sla/
Amazon Route53 サービスレベルアグリーメント
http://aws.amazon.com/jp/route53/sla/
また、保証といっても障害時に使用料の一部が返してもらえるだけ・・。
※稼働率99.99%を謳うS3も2017年3月には人為的ミスで5時間もダウンした

8. 性能・拡張性
性能
拡張性
AWSを利用する上でのハイライトの一つ。
サーバを自由にすぐ増やしたり減らしたりできるのは大きなメリット。
増やす＝性能、減らす＝コスト。
※ポイントはどうやってコンテンツを最新化するかというところ。

9. コンテンツ最新化の方法案
(1)各インスタンスが最新コンテンツを取得
コンテンツ コンテンツ
Web Web
CMS
S3最新
資材取得
最新
資材取得
コンテンツリリース
• 最新のコンテンツはストレージ領域（S3）に格納し、各インスタンスが
コンテンツを取得しに行く。
⇒AMIから新規に起動したインスタンスもコンテンツを取得することで最新化され
る。
• 各インスタンスからどのような方式でコンテンツを取得させるか検討が必要（コン
テンツリリースと同期、非同期的に定期的に確認する。など）
(2) 最新化される度にAMIを更新
• コンテンツのリリースが発生する度にAMIを更新し、新規に起動したインスタンスが最新
コンテンツの状態で起動する。
⇒コンテンツの更新頻度が高く、AMI更新中に新たなコンテンツが配置されるなどして、
静止点を設けることが難しい。
• コンテンツ資材の最新化もこの方式とする場合、新規に起動したインスタンスを検知し
て、そのインスタンスに対してもコンテンツをリリースをする作りが必要となる。
初期構築 コンテンツ更新 AutoScaling
コンテンツ
Web
AMI作成
コンテンツAMI
コンテンツ
Web
AMI更新
コンテンツAMI
コンテンツ
コンテンツ
AutoScaling
Web
新Web

10. 運用・保守性
AWSマネージメントコンソールはインターネットがあればどこから
でも接続できる。便利な反面、インターネット越しに、サーバの全消
去も可能という事！
MFA(Multi-Factor Authentication - Amazon AWS））
本番環境と開発環境が同じコンソールから操作できる。
※アカウントで制御は可能だが共通オブジェクトは制御不能
実際運用中に事故がおきた
運用
保守性

11. 運用・保守性
RDS（ORACLE）のパッチ適用ポリシー

12. セキュリティ
VPC(Virtual Private Cloud)：仮想的な閉域NW空間
 完全に隔離した閉域NW空間を確立し、サブネットを分割することでDMZ領域とプライベートな領域にNWを分離
SecurityGroup：ホストサーバ単位のファイアーウォール
 ホストサーバ(インスタンス)毎に受信/送信に対してフィルタリングによるファイアーウォールを実施
NetworkACL：サブネット単位のファイアーウォール
 NW分割されたサブネット毎に受信/送信に対してフィルタリングによるファイアーウォールを実施
データセンターネットワーク対策
 DDoS(Distributed Denial of Service)対策 ▶ AWS独自のDDoS緩和対策を使用
 Man In the Middle Attacks(中間者攻撃)対策 ▶ AWSリソースへのアクセス認証は全てSSLで保護
 IPスプーフィング対策 ▶ AmazonがソースIPとMacアドレスの整合性をチェックし送信元を偽装したデータをネットワークに送信不可
 ポートスキャン対策 ▶ インバウンドポートはデフォルトで不許可。ポートスキャンの検知、停止、ブロック対策を実施
 通信の盗聴対策 ▶ プロミスキャス・モードは不許可。ハイパーバイザーレベルで制御対策実施
WAF(ウェブアプリケーションファイアーウォール)
 SQLインジェクションやクロスサイトリクエストスクリプティングなどWebアプリケーションへの攻撃を防止
サーバ構成：
 不要なソフトウェアのアンインストール
 不要なプロセスの停止
 アカウント、パスワードの適正な管理

13. セキュリティ
明確化された
ガイドライン
への準拠
※ データセンタの所在、仕様など一部の情報に関しては非開示となりますが、これは悪意のあるユーザからの攻撃リスクを低減する事に繋がります。
これら非開示情報の妥当性は上記の第三者機関による認証によって担保されています。
専門的な
セキュリティ
技術要素の導
入
AWSでは、「共有セキュリティ責任モデル」が定義されており、システムセキュリティの責
任分界点が明確になっている。
共有セキュリティ責任モデル
アベイラビリティゾーン
リージョン
エッジロケーション
計算 ストレージ データベース ネットワーク
ネットワーク
セキュリティ
AWSリソース・
アカウント管理
データ
セキュリティ
アクセス
コントロール
アプリケーション&コンテンツ
AWS グローバルイ
ンフラストラクチャ
基盤サービス
AmazonAWS利用者
ユーザが責任を負う範囲については、IAMやSecurity
Groups、ACLといった機能が提供されており、要件に応じ
た設計が可能となっている。
DDoSなどの攻撃に対しては、AWSの専門的なセキュリティ
技術によって対策が実施されているため、利用者は考慮する
必要がない。

14. 環境・設備
環境
設備
AWS は Tier III+ ガイドラインに従ってデータセンターを運営しています
が、柔軟にパフォーマンスを拡大および向上できるよう、Uptime Institute
の階層レベルの認証を受けないことにしています。インフラストラク
チャーのパフォーマンスに対する AWS の手法では、Uptime Institute の階
層ガイドラインを認識したうえで、それをグローバルデータセンターのイ
ンフラストラクチャーの設計に適用することで、お客様に対する最高レベ
ルのパフォーマンスと可用性を実現しています。さらに、AWS は、Uptime
Institute によって提供されるガイドラインを強化して、グローバルオペ
レーションに対応できるよう拡張しています。これにより、可用性とパ
フォーマンスについて、Uptime Institute の階層ガイドライン単独で達成で
きるレベルをはるかに超える運営上の成果を実現しています。AWS は Tier
IV への準拠を明言しているわけではありませんが、システムには自己修正
対策が組み込まれており、耐障害性の高い運営手順が整備されていること
を確約できます
※AWSの資料より抜粋

15. まとめ

16. 最後に