2014.6.16 JAWS-UG長野キックオフで話したスライド

1. JAWS-UG長野キックオフ
AWS Essentials
2014.6.14
吉田真吾 @yoshidashingo
#nseg #jawsug

2. 自己紹介
吉田 真吾（よしだ しんご）
エバンジェリスト、ソリューションアーキテクト
AWSサムライ2014（Japan AWS UserGroup）
AWS Certified (All of them)
JAWS-UG横浜 代表
好きなAWSサービス
Amazon S3、Amazon Redshift
バックグラウンド
通信キャリア：基地局制御、GISサービス 開発
SIer：証券システム基盤 開発

3. アジェンダ
JAWS-UGって何？
AWSのメリット
AWSでよく使うサービス
AWSの一押しサービス
AWSのパートナービジネス
AWSの採用事例

4. JAWS-UG = Japan AWS User Group
Since 2010 from Tokyo
AWS小島さん資料より

5. AWS小島さん資料より

6. AWS小島さん資料より
宮崎
札幌
仙台
名古屋⼤大阪
⾦金金沢
京都
⼭山⼝口
佐賀 福岡
⿅鹿鹿児島沖縄
熊本
浜松
静岡
⻑⾧長崎
神⼾戸
⼤大分
湘南
岩⼿手
福井
徳島
広島
つくば
横浜
さいたま
⻑⾧長岡
函館
⻘青森
⼭山形
秋⽥田
中央線
島根
岡⼭山
北北九州
会津
千葉葉
東京
⾼高知
愛媛
うどん県
… and now there are 43 subsidiaries
in Japan. (as of 2014/3/15)

7. 祝！45支部 長野支部

8. AWS小島さん資料より
How AWS Japan built the community
Contributors in groups are key: Finding Key contributors by AWS from multiple
other communities and customers. Then, recruiting the contributes as leaders of the
community.
<Key Criteria>
Know the community’s activities
Good Skills in tech and human communications
Passion for knowing / teaching new technologies / business models
<For Example: JAWS-UG Tokyo>
AWS Book Authors
Java Community
Web Developers
Community
Customers
Bloggers on Cloud
Computing

9. AWS小島さん資料より
Key Triangle for community growth
[Study Group]
=> Information Exchange & Generation
[Drinking]
=> Know each other in person
[SNS/Web]
=> Keep and strengthen the engagement
Beginners for AWS
Join! Information feed
Encouraging & Mentoring
Feedbacks
Connect!!

10. AWS小島さん資料より
Connecting each community triangle…

11. AWS小島さん資料より
The Annual Conference of
JAWS-UG

12. AWS小島さん資料より
JAWS DAYS CONFERENCE
2014 March 15th (Sat)
・7 Tracks, 50+ Sessions
・Registration: 1,300 +
・Attendees: 1,000 +
・Party & Lightning Talks Session
Participants: 600 +

13. AWS小島さん資料より
AWS & JAWS-UG on major news program “World Business
Satellite” on TV Tokyo
Me

14. JAWS-UG東海道
http://jawsug-nagoya.doorkeeper.jp/events/10494

15. JAWS-UG大阪・京都・神戸
http://santo2014.jaws-ug.jp/

16. AWS Summit Tokyo 2014
http://www.awssummittokyo.com/

17. JAWS FESTA Tohoku 2014
http://jaws-ug.jp/es/jaws-festa-2014/

18. AWS小島さん資料より
You can start Today!

19. AWSのメリット

20. クラウド・コンピューティングの基本的な特徴
オンデマンド・ セルフサービス
幅広いネットワークアクセス
リソースの共用
スピーディな拡張性
サービスが 計測可能であること
http://www.ipa.go.jp/files/000025366.pdf

21. サービスモデル
Software as a Service
サービスの形で提供されるソフトウェア
Salesforce, Google Apps, Office 365
Platform as a Service
サービスの形で提供されるプラットフォーム
Engine Yard, Heroku, AWS Elastic Beanstalk
Infrastructure as a Service
サービスの形で提供されるインフラストラクチャ
Amazon Web Services, Windows Azure, Google Compute
Engine

22. サービスモデル
IaaS
PaaS
SaaS
構成
管理
ソフトウェ
ア管理
H/W
OS
ミドル
ウェア
H/W
OS
構成
管理
ミドル
ウェア
H/W
OS

23. AWSが解決する利用シーン

24. AWS資料より抜粋 http://s3.amazonaws.com/ppt-download/awsbasic20120629-120726021001-phpapp02.pdf

25. リージョン：地理的拠点
1リージョン内に複数のデータセンター
群（AZ）
地理的・電源的・ネットワーク的に分離
AZ間は高速専用線で接続
リージョンとアベイラビリティゾーン

27. http://www.slideshare.net/AmazonWebServicesJapan/on-aws-20130927

28. AWSでよく使うサービス

29. Amazon S3
オブジェクトストレージ
http/httpsでGETやPUTやLISTする
1B∼5TB/オブジェクト
容量は無制限
1GB=約3.3円/月
バケット>(フォルダ)>ファイル
静的コンテンツの配信も
アクティブでないデータは Glacier へ

31. Amazon EC2
仮想サーバー
さまざまなOS（UNIX、Linux、Windows）
AMI（マシンイメージ）からインスタンス化
ディスク
ローカル(エフェメラル)
Amazon EBS（永続。ネットワーク経由でアタッチ）
ネットワークセグメント：VPC by Default
ファイアウォール：Security Groups
固定IPv4：Elastic IPs
ライセンス（持ち込み／時間課金）

32. Amazon VPC
Security Groups
インスタンス単位の指定
接続元IPアドレスや接続ポートをインバウンド／
アウトバウンドで指定（ステートフル）
動的な追加／削除が行える
ネットワークACL（NACL）
サブネット単位の指定
ステートレスフィルター（インバウンド許可しててもアウトバウンド拒否すれば応答が
返らない）
ENIの追加が可能
ポートフォワーディングなども可
Security Group

33. Amazon EBS
仮想ディスク
容量
• 1GB∼1TB
EC2 EBS：ネットワーク
IOPS
• PIOPS：最大4000、設計4KB想定（ex. 32KB*4000 = 128MB/s = 1024Mbps とか計算してサチらないよう
にする）
• 通常：100＋バースト
帯域
• 特定のEC2インスタンスで EBS-Optimized：500Mbps or 1000Mbps
• 通常：保証なし

34. AWS が提供するロードバランシングサービス
AZをまたいでトラフィックをルートできる
• AZ間の振り分けは、負荷は見ずにDNSラウンドロビン
• AZ内では、バックエンドのEC2のリクエスト数やコネクション数を元に負
荷分散する
バックエンドのEC2をヘルスチェックして切り離すことが
できる
負荷に応じて自動的にスケールアウトする
• ELBのIPアドレスは変化するのでDNS名を利用する
CNAMEで独自ドメインを設定可能
Elastic Load Balancing

35. Elastic Load Balancing
AZをまたいでトラフィックをルートできる
AZ間の振り分けは、DNSラウンドロビン（デフォルト）かクロスゾーン負荷分散
AZ内では、バックエンドのEC2のリクエスト数やコネクション数を元に負荷分散する
スティッキーセッション
バックエンドのヘルスチェック
SSLターミネーション
接続元は「X-Forwarded-For」
ログ取得
負荷に応じて自動的にスケールアウト/インする
ELBのIPアドレスは変化するのでDNS名を利用する
Connection Draining で新規セッション受付停止＆セッション切断まで猶予
CNAMEで独自ドメインを設定可能

36. 共有ディスク
極力使わない
GlusterFS
FUSEクライアントによる競合とか
NFSサーバー
EIP側でマウントすると遅いとか
参照コンテンツだけなら S3

37. Auto Scaling
CloudWatch でリソースを監視して
負荷の状況に応じて EC2 を増減させる機能
Auto Scaling Group で EC2 を管理
ELB からはずされるとターミネートされる
設定要素
Launch Config：対象のEC2の設定
Auto Scaling Group：対象のEC2を管理するグループ
Scale Out Policy：スケールアウト（増）の設定
Scale In Policy：スケールイン（減）の設定

38. Amazon RDS
フルマネージドなデータベースサー
ビス
– 5.1, 5.5, 5.6
– Community Edition
– 11gR2
– EE, SE, SE-1
– 2008 R2, 2012
– EE, SE, Web, Express
– 9.3

39. Amazon RDS
バックアップ設定
人為的なオペレーションミスがあっても5分前まで戻
せる
Multi-AZ
ゾーンを跨がったHA構成（アクティブ／スタンバイ）
Oracle Database の場合、アクティブ／スタンバイ
両方にライセンスが必要
ブロックイメージの「同期」レプリケーション
DB Parameter Groups（各種パラメーターをラップし
ている）をチューニングする

40. 一般的な3-Tier構成

41. Amazon Redshift
フルマネージドなデータウェアハウ
スサービス
マルチノードの場合、クラスター内でデータが冗長化さ
れ、ノード障害時のフェイルオーバーや復旧が行われる
PostgreSQL ベース
ParAccell MPPのPostgreSQL v8.0.2 がベース（今も
そうかは分からないけど）

42. Amazon Redshift
接続方法
psql
• COPYコマンドを使ってS3や
DynamoDBからロード可能
JDBCやODBCのツール
• SQL WorkBenchやBIツール

43. Amazon Redshift
圧縮アルゴリズム
列ごとに圧縮方法の指定が可能
• RAW: 無圧縮
• Byte Dictionary: 辞書
• Delta: 前のデータとの差分化
• Mostly: 数値の出現頻度に応じて管理
• Run-length: 連長圧縮
• Text: Byte DictionaryのVARCHAR版
ANALYZEコマンドで推奨の圧縮アルゴリズムを示してくれる
テーブル0件で圧縮指定せずにロードすると先頭10万行から最
適な圧縮方法を推定して圧縮する

44. Amazon Redshift
DBパラメータチューニング
ワークロードマネジメント（WLM）
• User GroupsあるいはQuery Groupsによる
キューの分割
• キューごとの同時実行数、メモリ割当て
カーソル
• カーソルごとのメモリ割当てと同時使用カーソル数
SQLチューニング
Queriesタブの「Explain Plan」

48. WorkSpacesのネットワーク概要
48

49. 選べるマシンの種類
49

50. 選べるマシンの種類
50
クライアントアプリ

51. 選べるマシンの種類
51
クライアントアプリ

52. 選べるマシンの種類
52
WorkSpaces Sync

53. 選べるマシンの種類
53
WorkSpaces Sync

54. ディレクトリサービスとの統合
54
2種類

55. ディレクトリサービスとの統合
55
Cloud Directory

56. ディレクトリサービスとの統合
56
WorkSpace Connect

57. 活用シーンについて
57
社内業務端末として

58. 活用シーンについて
58
営業支援端末として
業務（端末）のDR対策として

59. パートナービジネス

61. AWSでビジネスが成立つ
http://ascii.jp/elem/000/000/885/885398/

62. PCI DSS、ISMS、Pマーク
取得済みの運用体制
コンサルティングや運用保守サービス

64. ソフトウェア販売

66. AWS採用事例

67. http://coiney.com/

68. PCI DSS要件
要件1: カード会員データを保護するために、ファイアウォールをインストール
して構成を維持する
要件2: システムパスワードおよび他のセキュリティパラメータにベンダ提供の
デフォルト値を使用しない
要件3: 保存されるカード会員データを保護する
要件4: オープンな公共ネットワーク経由でカード会員データを伝送する場合、
暗号化する
要件5: アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新
する
要件6: 安全性の高いシステムとアプリケーションを開発し、保守する
要件7: カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8: コンピュータにアクセスできる各ユーザに一意の ID を割り当てる
要件9: カード会員データへの物理アクセスを制限する
要件10: ネットワークリソースおよびカード会員データへのすべてのアクセス
を追跡および監視する
要件11: セキュリティシステムおよびプロセスを定期的にテストする
要件12: すべての担当者の情報セキュリティポリシーを整備する

69. FirewallIDS/IPS Firewall
アカウント管理
ログ集約管理
脆弱性対策脆弱性対策脆弱性対策

70. PCI DSS要件
要件1: カード会員データを保護するために、ファイアウォールをインストール
して構成を維持する
要件2: システムパスワードおよび他のセキュリティパラメータにベンダ提供の
デフォルト値を使用しない
要件3: 保存されるカード会員データを保護する
要件4: オープンな公共ネットワーク経由でカード会員データを伝送する場合、
暗号化する
要件5: アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新
する
要件6: 安全性の高いシステムとアプリケーションを開発し、保守する
要件7: カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8: コンピュータにアクセスできる各ユーザに一意の ID を割り当てる
要件9: カード会員データへの物理アクセスを制限する
要件10: ネットワークリソースおよびカード会員データへのすべてのアクセス
を追跡および監視する
要件11: セキュリティシステムおよびプロセスを定期的にテストする
要件12: すべての担当者の情報セキュリティポリシーを整備する
要件1: カード会員データを
保護するために、ファイア
ウォールをインストールし
て構成を維持する

71. PCI DSS要件
要件1: カード会員データを保護するために、ファイアウォールをインストール
して構成を維持する
要件2: システムパスワードおよび他のセキュリティパラメータにベンダ提供の
デフォルト値を使用しない
要件3: 保存されるカード会員データを保護する
要件4: オープンな公共ネットワーク経由でカード会員データを伝送する場合、
暗号化する
要件5: アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新
する
要件6: 安全性の高いシステムとアプリケーションを開発し、保守する
要件7: カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8: コンピュータにアクセスできる各ユーザに一意の ID を割り当てる
要件9: カード会員データへの物理アクセスを制限する
要件10: ネットワークリソースおよびカード会員データへのすべてのアクセス
を追跡および監視する
要件11: セキュリティシステムおよびプロセスを定期的にテストする
要件12: すべての担当者の情報セキュリティポリシーを整備する
要件5: アンチウィルスソフト
ウェアまたはプログラムを使
用し、定期的に更新する

72. セキュリティソフトウェア導入
Trend Micro Deep Security
IPS/IDS/改ざん検知/Firewall/WAF/ログ監視
ServerProtect
ウィルス対策（リアルタイムスキャン）

73. http://jp.trendmicro.com/jp/products/enterprise/tmds/pcidss/

74. セキュリティ＋
!
•
•

75. PCI DSS要件
要件1: カード会員データを保護するために、ファイアウォールをインストール
して構成を維持する
要件2: システムパスワードおよび他のセキュリティパラメータにベンダ提供の
デフォルト値を使用しない
要件3: 保存されるカード会員データを保護する
要件4: オープンな公共ネットワーク経由でカード会員データを伝送する場合、
暗号化する
要件5: アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新
する
要件6: 安全性の高いシステムとアプリケーションを開発し、保守する
要件7: カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8: コンピュータにアクセスできる各ユーザに一意の ID を割り当てる
要件9: カード会員データへの物理アクセスを制限する
要件10: ネットワークリソースおよびカード会員データへのすべてのアクセス
を追跡および監視する
要件11: セキュリティシステムおよびプロセスを定期的にテストする
要件12: すべての担当者の情報セキュリティポリシーを整備する
要件10: ネットワークリソース
およびカード会員データへの
すべてのアクセスを追跡および
監視する

76. アクセス記録・ログ集約管理
ログ管理
EC2インスタンス内に1週間分残す
fluentd経由でログサーバーへまとめ、S3へアーカイブ
[参考] FluentdでWeb Storage Archiveパターン
http://blog.cloudpack.jp/2013/01/aws-news-cdp-web-
storage-archive-fluentd.html

77. アクセス記録・ログ集約管理
ログ管理
サーバーだけでなく、ロードバランサやDBのログも取
得する必要がある

78. アクセス記録・ログ集約管理
Management Consoleアクセス制限とログ記録
多要素認証に加えて誰が何をしたか記録が必須
プロキシ経由のみアクセス可
プロキシサーバー上でアクセスログ記録
[参考] Squid経由でAWSマネジメントコンソールにアクセスしてソースIP制限や認証やログ取得
http://blog.cloudpack.jp/2013/02/aws-news-squid-aws-console-ip-log.html

79. ワンストップでサービス提供
PCI DSS準拠支援
QSA
インフラ構築
PCI DSS準拠対策
エンドユーザー
PCI DSSレベル1
サービスプロバイダ
PCI DSS準拠
インフラ構築サービス

81. →
東日本大震災を機に自社運用からAWSへ
ECシステム全体の移行（EC2約50台＋
RDS5台）
移行前サーバー構成調査
ミドルウェア構築
関連開発会社への情報共有
AWSシステムの構築・運用・監視

82. 初 インフラ構築
SAP環境構築
NTTデータグロー
バルソリューショ
ンズ
AWS環境構築
cloudpack
移行時のみインス
タンスタイプ変更 AWS導入事例紹介ページより引用
http://aws.amazon.com/jp/solutions/case-studies/
kenkocom/

83. 初 インフラ構築
SAP環境構築
NTTデータグロー
バルソリューショ
ンズ
AWS環境構築
cloudpack
移行時のみインス
タンスタイプ変更 AWS導入事例紹介ページより引用
http://aws.amazon.com/jp/solutions/case-studies/
kenkocom/
TCOが65%削減できた

86. インフラ設計・構築
インターネット公式サイト
月間1億PV 45億ヒット、
新車発表時3倍のアクセス
すべて冗長化
オンプレに環境再生可能な
バックアップ
東京リージョン障害時に
シンガポールで復旧可能

87. DR用CloudFormation
CloudFormationでシンガポールリージョ
ンに環境構築
テンプレートから一発で構築可能
Tokyo Region Singapore Region
CloudForma*on,
Template, Stack,

88. CDP
CloudFront
Clone Server
Multi-Datacenter
Cache Distribution
DB Replication
Bootstrap
Stack Deployment
HA NAT
DR

90. ヱヴァンゲリオン新劇場版：Q 公式サイトより引用
http://www.evangelion.co.jp/sp/news_det.php?new

91. サーバ構成

92. ウェブサーバーのスケールアウト
リクエスト処理キューイング
バッチサーバースケールアウト
インメモリDBスケールアウト

93. 設計・運用のポイント
対APIアクセスバースト対策
事前プロビジョニング（オートスケールじゃ
間に合わない）
キューイング・非同期戦略
負荷シミュレーション（負荷テスト）
TV視聴→スマホの膨大なアクセス
本番時現場チーム形成
状況に応じたリアルタイム対応

94. 1. Auto Scaling は使わずプロビジョニング
2. FB,Twttrへの投稿をキューイングして処理を疎結合化
3. キューサイズによってバッチサーバーを Auto Scaling
サーバ構成上のポイント
5.コンテンツのキャッシュ
7.DBの耐障害性＋可用性
6.Webサーバーの可用性
4.インメモリDBスケールアウト

95. 2. FB,Twttrへの投稿をキューイングして処理を疎結合化
3. キューサイズによってバッチサーバーを Auto Scaling
サーバ構成上のポイント

96. サーバ構成上のポイント
5.コンテンツのキャッシュ

97. サーバ構成上のポイント
6.Webサーバーの可用性

98. サーバ構成上のポイント
7.DBの耐障害性＋可用性

99. http://www.cloudpack.jp/
suuport@cloudpack.jp
@cloudpack_jp