Presented on Mar 11, 2017.

1. AWSでアプリ開発するなら
知っておくべこと
Keisuke Nishitani (@Keisuke69)
Amazon Web Services Japan K.K.
Mar 11, 2017

2. Profile
Keisuke Nishitani
Specialist Solutions Architect, Serverless
Amazon Web Service Japan K.K
@Keisuke69 Keisuke69
✤ ソーシャルで⾚ドクロの⼈です
✤ RESTおじさん
✤ 餃⼦の王将エヴァンジェリスト（⾃称）
✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます
✤ ブログ: http://keisuke69.hatenablog.jp/
Keisuke69 Keisuke69Keisuke69x

3. クラウドでのアプリケーション
✤ これまで通りの作り⽅をしたアプリもクラウド上で問題なく動く
✤ 既存のアプリケーションをクラウドに持ってくる事⾃体も難しくはない

4. クラウド向け
アーキテクチャとは？

5. スケーラビリティ

6. スケーラビリティ
✤ 運⽤中のシステムを拡張/縮⼩させる能⼒
✤ スケーラビリティを⽣かすことで可能になること
⎻ 柔軟性の向上(事業の必要性に応じたリソース確保)
⎻ コスト削減(必要な時に必要な分だけのリソース確保)
✤ スケールの種類
⎻ ⽔平スケーリング(スケールアウト/スケールイン)
⎻ 垂直スケーリング(スケールアップ/スケールダウン)

7. ⽔平・垂直のスケーリングの⽐較
✤垂直スケーリング
(スケールアップ/スケールダウン)
⎻ 個々のリソースのスペックを増減
⎻ リソースの限界が存在
⎻ インスタンスの停⽌が伴う
✤⽔平スケーリング
(スケールアウト/スケールイン)
⎻ リソースの台数を増減
⎻ 論理的には限界が存在しない
⎻ インスタンスの停⽌が伴わない
small large small
small small small
small small small
small small small

8. アーキテクチャの
ベストプラクティス

9. アーキテクチャのベストプラクティス

10. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン

11. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン
✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保

12. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン
✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤

13. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン
✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤
✤ Implement Elasticity: 弾⼒性の実装

14. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン
✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤
✤ Implement Elasticity: 弾⼒性の実装
✤ Think Parallel: 並列化

15. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン
✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤
✤ Implement Elasticity: 弾⼒性の実装
✤ Think Parallel: 並列化
✤ Loose Coupling: 疎結合

16. アーキテクチャのベストプラクティス
✤ Design for failure: 障害を前提としたデザイン
✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤
✤ Implement Elasticity: 弾⼒性の実装
✤ Think Parallel: 並列化
✤ Loose Coupling: 疎結合
✤ Don’t Fear Constraints: 制約を恐れない

17. Design for Failure

18. Everything fails, all the time.

19. Design for Failure
✤ 単⼀障害点をなくす
✤ すべてが失敗し得るという前提で考える
⎻ 仮に物理的なハードウェアが故障したり、削除したりリプレースされてもアプ
リケーションが機能し続けることがゴール
⎻ 個々のコンポーネントが失敗してもアプリケーション全体の停⽌を招かないよ
うにする

20. Design for Failure: 具体的には
✤最初に、1ホストを複数に分割する
⎻ Webとデータベース
✤データベース
⎻ Amazon RDSを利⽤するとより簡単
Web instance
Elastic IP
RDS DB
instance
User
Amazon
Route 53

21. Design for Failure: 具体的には
✤次に、フェイルオーバや冗⻑性
の問題を解決
✤複数のWebインスタンスを異な
るAZで
✤RDSはMulti-AZで
✤Elastic Load Balancing (ELB)を
利⽤して負荷分散
Web Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Web Instance
RDS DB Instance
Standby (Multi-AZ)
ELB Balancer
User
Amazon
Route 53

22. Build Security in Every Layer

23. Build Security in Every Layer
✤ すべてのレイヤーでセキュリティを確保
⎻ ⼀箇所でもセキュリティホールがあれば、そこを突かれてしまう
✤ 通信経路および保存されたデータの暗号化
✤ IAMを⽤いた最⼩権限の原則
✤ アプリケーションのロールごとに個別に制限されたSecurity Groupを
⽤意する
⎻ 外部へのアクセスはこれらで制限
✤ サブネットレベルでのトラフィック制限にNetworkACLを使う
✤ MFAを使⽤する

24. Build Security in Every Layer
Web Web Web Web
Private
Segment
(Web)
Public
Segment
Lo
g
Private
Segment
(DB)
Public Subnet (DMZ) Public Subnet (DMZ)
Private Subnet Private Subnet
Private Subnet Private Subnet
NAT NAT
操作ログ
リソース監視
通知
データ暗号化
権限管理
【サブネット】
外部からアクセスできるサブ
ネットと、外部からはアクセ
スできないサブネットの作成
【ネットワークアクセス制御】
SecurityGroup及びNetwork
ACLを使ってアクセス制御を実
施
【保管するデータの暗号化】
S3やEBS、RDSといったスト
レージサービス上のデータを暗
号化
【アクセス管理】
AWSアカウント・IAMユー
ザーの管理。AWSリソース
へのアクセス制御(最⼩権限
の原則を順守可能)
【AWS操作ログ】
AWS操作ログの取得（管理コン
ソールやCLI含む）
【AWSサービス監視】
各種AWSサービス（ELB、RDS、
EC2等）のリソース監視
Availability Zone Availability Zone
詳細： http://www.slideshare.net/AmazonWebServicesJapan/awswebinar-aws-56260969

25. 提供されている機能の活⽤
✤ 提供されている便利なセキュリティ機能を活⽤することでよりシンプ
ルにセキュリティ確保が可能に
✤ AWS が提供するセキュリティ機能活⽤の例
⎻ AWS IAM による権限制御
⎻ セキュリティグループによるアクセスコントロール
⎻ AWS WAF による DDoS 緩和
⎻ AWS CloudTrail による監査ログ取得
⎻ AWS KMS による暗号化鍵管理
⎻ etc

26. リアルタイム監査
✤ 継続的にコンプライアンスのための監視を実施
⎻ AWS Config
⎻ Amazon Inspector
⎻ AWS Trusted Advisor
✤ AWS環境の操作ログの取得
⎻ AWS CloudTrail
✤ アプリケーションログの収集
⎻ Amazon CloudWatch Logs

27. Leverage Many Storage Options

28. Leverage Many Storage Options
✤ 万能なデータストアは存在しない
✤ データストアの特性(得意不得意)に応じて使い分ける

29. Leverage Many Storage Options
✤ ストレージの使い分け
File/Block Storage
Object Storage
• ⾼可⽤
• ⼤容量
• 静的コンテン
ツ配信
• 低価格
• アーカイブ
• NFS
• 共有ディスク
• ⾼IOPS
• 低レイテンシ
• 永続化
• 任意のファイルシ
ステム
Amazon S3 Amazon Glacier
Amazon EFS Amazon EBS

30. Leverage Many Storage Options
✤ データベースの使い分け
Amazon DynamoDB
Amazon RDS
Amazon ElastiCache
Amazon Redshift
SQL
NoSQL• 低レイテンシ
• インメモリ
• 3拠点間での
レプリケーション
• SSDに永続化
• トランザク
ション処理
• 汎⽤⽤途
• 集計・分析処理
• ⼤容量データ
• DWH

31. Leverage Many Storage Options
✤静的コンテンツはS3に
✤セッションやステートはAmazon
DynamoDBに
✤DBのキャッシュはAmazon
ElastiCacheに
RDS DB Instance
Active (Multi-AZ)
Availability Zone
ELB
Amazon S3
Amazon
CloudFrontUser
ElastiCache DynamoDB
Web Instances
Amazon
Route 53

32. Implement Elasticity

33. Implement Elasticity
✤ コンポーネントの正常性、可⽤性、固定されたロケーションを前提と
しない
⎻ IPアドレスで参照しない、分散させるなど
✤ リブートや機能停⽌に対して弾⼒性のあるデザインを⾏う
✤ インスタンスのブートストラップ
⎻ インスタンスが起動する時に、⾃分⾃⾝が誰で役割が何かを問い合わせる
✤ 動的な構成を優先する

34. Think Parallel

35. Think Parallel
✤ 様々な並列アーキテクチャを試す
✤ クラウドサービスに対するマルチスレッドや並列リクエストの利⽤
⎻ EMRを⽤いて並列のMapReduceジョブを実⾏
⎻ ロードバランサ（ELB）を⽤いた負荷分散
⎻ 1つのKinesis Streamと複数のKCLアプリケーション
⎻ バックエンドとしてのLambdaの利⽤

36. Think Parallel: バッチ処理の例
✤ 1インスタンスでN時間かけるのもN台を使って1時間で処理するのも
コストとしては同じ

37. Loose Coupling

38. Loose Coupling
✤ 独⽴したコンポーネントを⽤いたアーキテクチャデザイン
⎻ コンポーネント間の結合度が緩やかになるほど、スケーラビリティは⾼まる
✤ すべてのコンポーネントをブラックボックスとしてデザイン
⎻ 個々のリソースに固有の情報に依存しない
⎻ 必要な情報だけをわたし、API でアクセス
⎻ IP アドレスではなく DNS 名でアクセス
⎻ 処理を実施するインスタンスへの直接アクセスを避け、
ELB, SQS へアクセスさせるよう設計
✤ 負荷分散のためのクラスタ

39. Loose Coupling
✤ キューを利⽤して疎結合なコンポーネント間でメッセージを受け渡し
密結合
キューを⽤いた疎結合
Component1 Component2 Component3
Component1 Component2 Component3
Q QQ

40. Loose Coupling
✤ 結合度が緩やかになるほど、スケーラビリティは⾼まる
⎻ 独⽴したコンポーネント
⎻ すべてのコンポーネントをブラックボックスとしてデザイン
⎻ インタラクションの切り離し
⎻ 独⾃で構築するよりも、冗⻑性とスケーラビリティが組み込まれているサービ
スを活⽤する
S3 Bucket
Lambda
Push: Event
Notification
DynamoDB
Pull: DynamoDB
Stream
Amazon
Kinesis
Pull:
DynamoDB Stream
SQS
messages
Get
Message
Instance
Put
Message
Instance
Amazon SNS Topic
Publish
Notification
Queue Is Subscribed
to Topic

41. Service Discovery

42. Service Discovery
✤ 個々のサービスがブラックボックスとしてお互いにやり取りをするには、
各サービスで増えたリソース、減ったリソースに対して透過的にアクセス
できる必要がある
✤ Service Discovery の例
⎻ Auto Scaling を使ったインスタンスの ELB への⾃動登録
⎻ EC2 ユーザーデータ × Amazon Route 53
⎻ Auto Scaling Life Cycle Hook × Amazon Route 53
⎻ 3rd party solutions
⎻ Netflix Eureka
⎻ Airbnb Synapse
⎻ HashiCorp Consul
⎻ etc

43. Asynchronous Integration

44. Asynchronous Integration
✤ 同期処理である必要がなければ⾮同期にする
⎻ その処理、本当にレスポンス必要ですか？
✤ ⾮同期処理の利点
⎻ ユーザ側の利点
⎻ アプリケーションがブロックされない
⎻ サーバ側の利点
⎻ スケーラブルかつ⾼可⽤なバックエンド
⎻ Frontend を停⽌させることなく Backend を容易にメンテナンス可能
⎻ 少ないFrontend のキャパシティで多くのリクエストを受付可能
⎻ リクエストの処理順序やリトライ等の制御が容易に

45. Don’t Fear Constraints

46. Don’t Fear Constraints
✤ より多くのメモリが必要？
⎻ 負荷を分散させる、キャッシュの利⽤を検討

47. Don’t Fear Constraints
✤ より多くのメモリが必要？
⎻ 負荷を分散させる、キャッシュの利⽤を検討
✤ データベースにさらなるIOPSが必要？
⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討
⎻ PIOPS、SSDベースのインスタンスストレージ
⎻ ElastiCacheを使ったデータベースのキャッシング

48. Don’t Fear Constraints
✤ より多くのメモリが必要？
⎻ 負荷を分散させる、キャッシュの利⽤を検討
✤ データベースにさらなるIOPSが必要？
⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討
⎻ PIOPS、SSDベースのインスタンスストレージ
⎻ ElastiCacheを使ったデータベースのキャッシング
✤ ハードウェア障害や設定が壊れてしまった
⎻ シンプルに問題のあるインスタンスを破棄し、置き換える

49. The Twelve-Factor App

50. The Twelve-Factor App
✤ 元はHerokuのエンジニアが公開したモダンなWebアプリケーション
開発のための⽅法論
⎻ 直接的にクラウドと関連する話しではないが、少なくともWebエンジニアは⼀
読しておくべき
✤ Dockerによるアプリケーション開発やLambdaのようなサーバレスコ
ンピュートの普及に伴い、改めて重要性が増しつつある
✤ URL
http://12factor.net/
http://12factor.net/ja/（⽇本語訳）

51. The Twelve-Factor App
✤ Codebase - コードベース -
⎻ バージョン管理されている1つのコードベースと複数のデプロイ
⎻ デプロイされているアプリとコードベースは常に1:1であるべき
✤ Dependencies - 依存関係 -
⎻ 依存関係を明⽰的に宣⾔し分離する
⎻ 特定の環境に暗黙的にインストールされているパッケージやツールに依存しな
いこと
⎻ アプリケーションが必要とするツール、ライブラリはアプリケーションに同梱
されるべき

52. The Twelve-Factor App
✤ Config - 設定 -
⎻ 環境によって異なる設定はOSレベルの環境変数によって注⼊されるべきである
✤ Backing services - バックエンドサービス -
⎻ アプリケーションがネットワーク越しに利⽤するようなサービスはすべてリ
ソースとして扱う
⎻ データベースやメッセージブローカーといったものはアタッチされたリソース
として扱う
⎻ ローカル環境も本番もサードパーティもどれもリソースとして扱い、それらの
切り替えはリソースハンドルの切り替えとする

53. The Twelve-Factor App
✤ Build, release, run - ビルド、リリース、実⾏ -
⎻ ビルド、リリース、実⾏の3つのステージを厳密に分離する
⎻ それぞれのリリースは⼀意のIDを持つべき
✤ Process - プロセス -
⎻ アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏す
る
⎻ プロセス間で何も共有はしない
⎻ 永続化する必要のあるデータはDBなどのステートフルな外部サービスを⽤いる
⎻ ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとし
て扱い、永続化されることを期待しない

54. The Twelve-Factor App
✤ Port binding - ポートバインディング -
⎻ ポートバインディングを通してサービスを公開する
⎻ Webアプリケーション⾃体がサービスとなってリクエストを待ち受けること
⎻ リクエストを受け付ける何かを⽤意するのではなく、アプリに組み込まれるべき
✤ Concurrency - 並⾏性 -
⎻ プロセスモデルによってスケールアウトする
⎻ ⽔平⽅向へのプロセスのスケールアウトによって並⾏性を担保する

55. The Twelve-Factor App
✤ Disposability - 廃棄容易性 -
⎻ ⾼速な起動と簡単な廃棄
⎻ グレースフルシャットダウン
✤ Dev/prod parity - 開発/本番⼀致 -
⎻ 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ
⎻ CI/CDは各環境が揃っていることで実現される
✤ Log - ログ -
⎻ 出⼒ストリームの保存先やルーティングには関与しない
⎻ ログファイルへの書き出しや管理などをアプリ側ですべきではない
⎻ シンプルに標準出⼒に吐き出すだけ
⎻ 本番環境などではそれを集めて、保存し、インデックス化し分析する環境をアプリの外に⽤意
する
✤ Admin processes - 管理プロセス -
⎻ 管理タスクを1回限りのプロセスとして実⾏する

56. ⽔平スケーリングを⾏うために⼼がけること
✤ ステートレスアプリケーション/コンポーネント
⎻ ステートフルになる要素を⽔平スケールするリソースの外部に配置
⎻ セッション情報は、DynamoDB/ElastiCache へ
⎻ バイナリファイル, ログなどは、 Amazon S3 へ
✤ ステートフルになるコンポーネントをどう扱うか
⎻ ⽔平スケールするマネージドサービスの利⽤
⎻ ⽔平スケールができない場合に注意すべき制約を洗い出す
✤ 分散処理（今までのやり⽅を⾒直す）
⎻ ⻑時間かかっていた単⼀のタスクを分割できないか検討
⎻ 1台のサーバで4時間かかるタスクを、4台のサーバで1時間でこなす
✤ 商⽤ライセンスの扱い
⎻ ライセンスの提供元に確認

57. ステートレスにするためのセッション情報の扱い
✤スケールアウト時
⎻ スケールアウトしたリソースが使わ
れにくい
✤スケールイン時
⎻ セッションも⼀緒に落とすことにな
るので、困難
Web/
App
Auto
Scaling
ELB
Client
Web/
App
Web/
App
セッション
既存ユーザのセッショ
ンは、既存のコンポー
ネントにあるため、リ
クエストは、同じリ
ソースへ
Sticky
Session
スケールアウトしたリ
ソースを活かしにくい
Web/
App
Auto
Scaling
ELB
Client
Web/
App
セッション
インスタンスを削除す
ると、既存ユーザの
セッション情報も失わ
れてしまう(ログアウト
された挙動となる)
Sticky
Session

58. ステートレスにするためのセッション情報の扱い
✤ スケールさせやすくするためにセッション情報は外だし
Web/
App
Auto
Scaling
ELB
Client
Web/
App
DynamoDB
セッション情報
ElastiCache
or
書き換えられても問
題ない情報、肥⼤化
の恐れがない情報は
Client-Side で保持す
ることも可能
Client-Side で書き換え
られると困る情報は
Server-Side で保持
各リソースに固有の情報がないの
で、いつでも増減しやすい

59. DevOps

60. Why DevOps?
✤ ビジネスのスピードと多様性はより⼀層増している
⎻ 何が当たるかわからない
⎻ 事業環境の変化
⎻ 事前に予測しきるのは難しい
⎻ 本当に求められているのは何なのか
✤ ビジネスを成功に導くためのITの重要性の⾼まり

61. Why DevOps?
✤ ビジネスのスピードと多様性はより⼀層増している
⎻ 何が当たるかわからない
⎻ 事業環境の変化
⎻ 事前に予測しきるのは難しい
⎻ 本当に求められているのは何なのか
✤ ビジネスを成功に導くためのITの重要性の⾼まり
素早い変化への対応が必要

62. What is DevOps?

63. What is DevOps?
⽂化
Culture
実践
Practice
ツール
Tool

64. What is DevOps?
⽂化
Culture
実践
Practice
ツール
Tool

65. What is DevOps?
⽂化
Culture
✤ コラボレーション
✤ 壁をなくす
⎻ チーム間
⎻ 中間プロセス
✤ End to EndでOne teamであること
✤ 直接的に関係する個⼈に対する責任は減らす
✤ ⾏われた作業の結果に対する可視性を⾼める

66. What is DevOps?
実践
Practice
✤ Automate Everything
✤ Test Everything
✤ 継続的インテグレーション
⎻ アプリケーションのテスト/QAは開発中ずっ
と⾏う
✤ 継続的デリバリ
⎻ 環境をまたいだコードの⾃動デプロイ
✤ Infrastructure as Code
✤ Canary, Blue-Green and Red-Black デプロイメ
ント
✤ セルフサービスな環境
⎻ 調達ブロッカーをなくす
✤ Microservices
⎻ 複雑なモノリシックアプリケーションを⼩さ
なものへブレイクダウン

67. Elastic
Beanstalk
CloudFormationOpsWorks
⾃動化と構成管理
✤ 宣⾔的なアプローチ
⎻ プロビジョニング
⎻ 設定
⎻ オーケストレーション
⎻ レポーティング
CodeDeploy

68. 継続的インテグレーション（CI）と継続的デリバリ（CD）
✤ 結果を事前定義し、コードの品質と機能を繰り返し検証する
✤ 多様なツール群: ⾃社開発、オープンソース、プロプライエタリ製品、
SaaS
✤ モニタリング、テスト、検証
AWS
CodeDeploy
AWS
CodePipeline

69. 継続的インテグレーション（CI）と継続的デリバリ（CD）
✤ アプリケーションとインフラストラクチャの両⽅
✤ 可能な限り⾃動化する
✤ 宣⾔的にインフラを定義
✤ セキュリティを含め注意深くインフラを設計
✤ 定義や設定をアプリケーションコードのごとく扱う
✤ バージョンコントロール
✤ アプリケーションの⼀部としてのインフラ
✤ ロールバックのためのプラン
✤ モニタリング、ロギングと監査
Introduction to Microservices
DevOps and AWS

70. Version Control
Build/
Compile
Code
Dev
Unit Test
App Code
IT Ops ENV
DR
Test
Prod
Dev
Application
Write
App Code
Infrastructure
AWS CloudFormation
tar, war, zip
yum, rpmDeploy
App
Package
Application
Build
AMIs
Validate
Templates
Write
Infra Code
Deploy
Infras
Automate
Deployment
Artifact Repository
Only deploys application
Only deploys infrastructure
AWS CodeDeploy
CI/CDと⾃動化

71. What is DevOps?
ツール
Tool
✤ ⾃動化とCI/CDのためのツール
⎻ Pipeline管理ツール
⎻ ソースコード管理ツール
⎻ テストフレームワーク/テストツール
⎻ コードレビュー/フィードバックツール
⎻ コードの静的解析ツール
⎻ デプロイツール
✤ ⼀貫性のある、予測可能なアプリケーション管理
と設定管理
✤ インフラストラクチャの計測
⎻ メトリクス
⎻ ロギング
⎻ モニタリング
⎻ APM(Application Performance Monitoring)
✤ セキュリティの分析と管理ツール

72. What is DevOps?
DevOps =
開発者 顧客
releasetestbuild
plan monitor
デリバリのパイプライン
フィードバックループ
ソフトウェア開発のライフサイクル
無駄やボトルネックを取り除くことで、
ライフサイクルを効率化し、⾼速化すること

73. DevOps Tools on AWS

74. Networking AnalyticsCompute
Storage & Content Delivery
Developer Tools Management Tools
Security & Identity
Mobile Services Database Business Productivity,
Desktop & App Streaming
S3 CloudFront EFS Glacier
Storage
Gateway
AppStream
CloudSearch
SESSQS
Mobile A
nalytics
Cognito Device Farm
SNS
RDS DynamoDB ElastiCache RedShift WorkSpaces WorkDocs WorkMail
Lambda ECSEC2 VPC Direct Connect Route 53 EMR Data Pipeline KinesisELB QuickSight Elasticsearch
Service
CodeCommit
CloudWatch Cloud
Formation
CloudTrail Config OpsWorks Service C
atalog
IAM Directory
Service
Trusted A
dvisor
WAFSnowball
DMS
IoT
IoT
Game Dev
Mobile Hub
ElasticBeanstalk
ACM Inspector
GameLift
CodePipeline
CodeDeploy
ほとんどのサービスに⽤意されたAPI
Lightsail AWS Batch
Application Discovery
Service
SMS
Pinpoint
Application Services
API Gateway Elastic Transcoder SWF Step Functions
Messaging
Migration
X-Ray
CodeBuild
Amazon Lex Amazon Polly
AI
LexPolly Rekognition Machine
Learning
KMS ShieldOrganizations

75. SDK
Ruby
iOS
Python (boto)
Android Node.js
AWS Toolkit
for Visual
Studio
.NET
AWS Toolkit
for Eclipse
PHP
AWS Tools
for Windows
PowerShell
AWS CLI
JavaScriptJava
Xamarin

76. クラウドならではのメリット
76
オンプレミス
新しいインフラの構築は
複雑かつ遅くなりがち
クラウド
ワンクリックで新しい
インフラを⽤意
新しいデプロイ環境を構築
新しいテスト環境を構築
新しい環境を海外に構築
1,000 サーバ追加
1,000 サーバ削除
必要 調査 評価
計画 設計 エンジニア
調達 契約 コミッション
デプロイ

77. MonitorProvisionDeployTestBuildCode
Elastic Beanstalk
OpsWorks
Cloud
Watch
Cloud
Formation
Code
Deploy
Code
Commit
Code
Build
AWS DevOps Services
Code
Pipeline
Third
Party
Tools

78. Jenkinsを使ったデプロイ
✤ 多くのプラグインが利⽤可能
✤ CIとCDに使われている
✤ CodePipelineからの呼び出しが可能
✤ GitHubのWebHookによるイベント受信
✤ Dockerイメージをデプロイするプラグインも利⽤可能

79. JenkinsとDockerを使った継続的デリバリ
Introduction to Microservices
DevOps and AWS
Bucket
Amazon ECS
AWS CloudFormation
ECS Cluster

80. コンテナのメリット
Portable
Flexible
Fast
Efficient
Server
Guest OS
Bins/Libs Bins/Libs
App2App1

81. Dockerの特徴
Package
Ship
Run

82. Cluster Management

83. $ docker run myimage
Server
Guest OS
Bins/Libs Bins/Libs
App2App1

85. Amazon EC2 Container Service (ECS)
✤ 管理ノード不要の、安定かつ⾼パフォーマンスなクラスタ管理サービス
✤ Dockerコンテナを複数のEC2インスタンスに分散配置
✤ ⼀時的な計算処理にも、ロングランニングな処理にも対応
✤ ELB連携など各種AWSサービスとの親和性
✤ Amazon ECS⾃体の利⽤は無料
複数のコンテナをEC2のクラスタ上で⼀元管理できるサービス

86. その他のベストプラクティス
✤ CI/CDは必須
⎻ 頻繁なコミットとコミットごとのビルド
⎻ 実際に稼働する環境を⽤いたテスト
✤ コードのすべてをコードリポジトリに保管
⎻ アプリ、インフラ、ドキュメント
⎻ リポジトリ上にないものはプロダクションに持っていってはいけない
✤ コードレビューは良いコードのためのベストな⽅法
⎻ クリーンで誰もが理解できるコードか？
⎻ 設計がニーズを満たせているか？
⎻ 同じことをするのにより良い⽅法、簡単な⽅法はないか？

87. その他のベストプラクティス
✤ ⾃動ロールバック
⎻ 失敗時における最も速いリカバリのメカニズムと⾔える
⎻ まずはロールバックし、その後ログ/グラフなどを⽤いてデバッグする
✤ ダッシュボードを通じて状況を把握する
⎻ 今何がおきているか？
⎻ 通常時はどのように⾒えているのか？
⎻ グラフがおかしかったり、アラームが発⽣した場合に何をするのか？
⎻ グラフ内の動きはどのようなイベントと紐付けられるのか？

88. Conclusion
✤ クラウドを最⼤限に活かすには、アプリケーションをスケーラブルに
作ること
✤ スケーラブルなアプリケーションを作るための⽅法論はいくつかあり、
適宜⾃分たちにあわせて選択をしていくこと
✤ 忘れちゃいけないDevOps
⎻ というかCIとCD
⎻ すべてを頻度⾼くテストする