More Related Content Similar to AWSでアプリ開発するなら 知っておくべこと (20) More from Keisuke Nishitani (20) AWSでアプリ開発するなら 知っておくべこと2. Profile
Keisuke Nishitani
Specialist Solutions Architect, Serverless
Amazon Web Service Japan K.K
@Keisuke69 Keisuke69
✤ ソーシャルで⾚ドクロの⼈です
✤ RESTおじさん
✤ 餃⼦の王将エヴァンジェリスト(⾃称)
✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます
✤ ブログ: http://keisuke69.hatenablog.jp/
Keisuke69 Keisuke69Keisuke69x
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: 制約を恐れない
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
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
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
35. Think Parallel
✤ 様々な並列アーキテクチャを試す
✤ クラウドサービスに対するマルチスレッドや並列リクエストの利⽤
⎻ EMRを⽤いて並列のMapReduceジョブを実⾏
⎻ ロードバランサ(ELB)を⽤いた負荷分散
⎻ 1つのKinesis Streamと複数のKCLアプリケーション
⎻ バックエンドとしてのLambdaの利⽤
38. Loose Coupling
✤ 独⽴したコンポーネントを⽤いたアーキテクチャデザイン
⎻ コンポーネント間の結合度が緩やかになるほど、スケーラビリティは⾼まる
✤ すべてのコンポーネントをブラックボックスとしてデザイン
⎻ 個々のリソースに固有の情報に依存しない
⎻ 必要な情報だけをわたし、API でアクセス
⎻ IP アドレスではなく DNS 名でアクセス
⎻ 処理を実施するインスタンスへの直接アクセスを避け、
ELB, SQS へアクセスさせるよう設計
✤ 負荷分散のためのクラスタ
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
44. Asynchronous Integration
✤ 同期処理である必要がなければ⾮同期にする
⎻ その処理、本当にレスポンス必要ですか?
✤ ⾮同期処理の利点
⎻ ユーザ側の利点
⎻ アプリケーションがブロックされない
⎻ サーバ側の利点
⎻ スケーラブルかつ⾼可⽤なバックエンド
⎻ Frontend を停⽌させることなく Backend を容易にメンテナンス可能
⎻ 少ないFrontend のキャパシティで多くのリクエストを受付可能
⎻ リクエストの処理順序やリトライ等の制御が容易に
47. Don’t Fear Constraints
✤ より多くのメモリが必要?
⎻ 負荷を分散させる、キャッシュの利⽤を検討
✤ データベースにさらなるIOPSが必要?
⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討
⎻ PIOPS、SSDベースのインスタンスストレージ
⎻ ElastiCacheを使ったデータベースのキャッシング
48. Don’t Fear Constraints
✤ より多くのメモリが必要?
⎻ 負荷を分散させる、キャッシュの利⽤を検討
✤ データベースにさらなるIOPSが必要?
⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討
⎻ PIOPS、SSDベースのインスタンスストレージ
⎻ ElastiCacheを使ったデータベースのキャッシング
✤ ハードウェア障害や設定が壊れてしまった
⎻ シンプルに問題のあるインスタンスを破棄し、置き換える
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回限りのプロセスとして実⾏する
66. What is DevOps?
実践
Practice
✤ Automate Everything
✤ Test Everything
✤ 継続的インテグレーション
⎻ アプリケーションのテスト/QAは開発中ずっ
と⾏う
✤ 継続的デリバリ
⎻ 環境をまたいだコードの⾃動デプロイ
✤ Infrastructure as Code
✤ Canary, Blue-Green and Red-Black デプロイメ
ント
✤ セルフサービスな環境
⎻ 調達ブロッカーをなくす
✤ Microservices
⎻ 複雑なモノリシックアプリケーションを⼩さ
なものへブレイクダウン
71. What is DevOps?
ツール
Tool
✤ ⾃動化とCI/CDのためのツール
⎻ Pipeline管理ツール
⎻ ソースコード管理ツール
⎻ テストフレームワーク/テストツール
⎻ コードレビュー/フィードバックツール
⎻ コードの静的解析ツール
⎻ デプロイツール
✤ ⼀貫性のある、予測可能なアプリケーション管理
と設定管理
✤ インフラストラクチャの計測
⎻ メトリクス
⎻ ロギング
⎻ モニタリング
⎻ APM(Application Performance Monitoring)
✤ セキュリティの分析と管理ツール
72. What is DevOps?
DevOps =
開発者 顧客
releasetestbuild
plan monitor
デリバリのパイプライン
フィードバックループ
ソフトウェア開発のライフサイクル
無駄やボトルネックを取り除くことで、
ライフサイクルを効率化し、⾼速化すること
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
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は必須
⎻ 頻繁なコミットとコミットごとのビルド
⎻ 実際に稼働する環境を⽤いたテスト
✤ コードのすべてをコードリポジトリに保管
⎻ アプリ、インフラ、ドキュメント
⎻ リポジトリ上にないものはプロダクションに持っていってはいけない
✤ コードレビューは良いコードのためのベストな⽅法
⎻ クリーンで誰もが理解できるコードか?
⎻ 設計がニーズを満たせているか?
⎻ 同じことをするのにより良い⽅法、簡単な⽅法はないか?