awsでアプリ開発するなら 知っておくべこと
TRANSCRIPT
AWSでアプリ開発するなら知っておくべこと
Keisuke Nishitani (@Keisuke69)Amazon Web Services Japan K.K.
Mar 11, 2017
ProfileKeisuke NishitaniSpecialist Solutions Architect, ServerlessAmazon Web Service Japan K.K
@Keisuke69 Keisuke69
✤ ソーシャルで⾚ドクロの⼈です✤ RESTおじさん✤ 餃⼦の王将エヴァンジェリスト（⾃称）✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます✤ ブログ: http://keisuke69.hatenablog.jp/
Keisuke69 Keisuke69Keisuke69x
クラウドでのアプリケーション
✤ これまで通りの作り⽅をしたアプリもクラウド上で問題なく動く
✤ 既存のアプリケーションをクラウドに持ってくる事⾃体も難しくはない
クラウド向けアーキテクチャとは？
スケーラビリティ
スケーラビリティ✤ 運⽤中のシステムを拡張/縮⼩させる能⼒
✤ スケーラビリティを⽣かすことで可能になること⎻ 柔軟性の向上(事業の必要性に応じたリソース確保)⎻ コスト削減(必要な時に必要な分だけのリソース確保)
✤ スケールの種類⎻ ⽔平スケーリング(スケールアウト/スケールイン)⎻ 垂直スケーリング(スケールアップ/スケールダウン)
⽔平・垂直のスケーリングの⽐較✤垂直スケーリング
(スケールアップ/スケールダウン)⎻ 個々のリソースのスペックを増減⎻ リソースの限界が存在⎻ インスタンスの停⽌が伴う
✤⽔平スケーリング(スケールアウト/スケールイン)
⎻ リソースの台数を増減⎻ 論理的には限界が存在しない⎻ インスタンスの停⽌が伴わない
small large small
small small small
small small small
small small small
アーキテクチャのベストプラクティス
アーキテクチャのベストプラクティス
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤✤ Implement Elasticity: 弾⼒性の実装
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤✤ Implement Elasticity: 弾⼒性の実装✤ Think Parallel: 並列化
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤✤ Implement Elasticity: 弾⼒性の実装✤ Think Parallel: 並列化✤ Loose Coupling: 疎結合
アーキテクチャのベストプラクティス✤ Design for failure: 障害を前提としたデザイン✤ Build Security in Every Layer: すべてのレイヤでセキュリティを担保✤ Leverage Many Storage Options: 複数のストレージオプションを活⽤✤ Implement Elasticity: 弾⼒性の実装✤ Think Parallel: 並列化✤ Loose Coupling: 疎結合✤ Don’t Fear Constraints: 制約を恐れない
Design for Failure
Everything fails, all the time.
Design for Failure✤ 単⼀障害点をなくす
✤ すべてが失敗し得るという前提で考える⎻ 仮に物理的なハードウェアが故障したり、削除したりリプレースされてもアプ
リケーションが機能し続けることがゴール⎻ 個々のコンポーネントが失敗してもアプリケーション全体の停⽌を招かないよ
うにする
Design for Failure: 具体的には✤最初に、1ホストを複数に分割する
⎻ Webとデータベース
✤データベース⎻ Amazon RDSを利⽤するとより簡単
Webinstance
ElasticIP
RDSDBinstance
UserAmazonRoute53
Design for Failure: 具体的には✤次に、フェイルオーバや冗⻑性の問題を解決
✤複数のWebインスタンスを異なるAZで
✤RDSはMulti-AZで
✤Elastic Load Balancing (ELB)を利⽤して負荷分散
WebInstance
RDSDBInstanceActive(Multi-AZ)Availability Zone Availability Zone
WebInstance
RDSDBInstanceStandby(Multi-AZ)
ELBBalancer
UserAmazonRoute53
Build Security in Every Layer
Build Security in Every Layer✤ すべてのレイヤーでセキュリティを確保
⎻ ⼀箇所でもセキュリティホールがあれば、そこを突かれてしまう✤ 通信経路および保存されたデータの暗号化✤ IAMを⽤いた最⼩権限の原則✤ アプリケーションのロールごとに個別に制限されたSecurity Groupを
⽤意する⎻ 外部へのアクセスはこれらで制限
✤ サブネットレベルでのトラフィック制限にNetworkACLを使う✤ MFAを使⽤する
Build Security in Every Layer
Web Web Web Web
Priv
ate
Segm
ent
(Web
)Pu
blic
Se
gmen
t
Log
Priv
ate
Segm
ent
(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
提供されている機能の活⽤✤ 提供されている便利なセキュリティ機能を活⽤することでよりシンプ
ルにセキュリティ確保が可能に
✤ AWS が提供するセキュリティ機能活⽤の例⎻ AWS IAM による権限制御⎻ セキュリティグループによるアクセスコントロール⎻ AWS WAF による DDoS 緩和⎻ AWS CloudTrail による監査ログ取得⎻ AWS KMS による暗号化鍵管理⎻ etc
リアルタイム監査✤ 継続的にコンプライアンスのための監視を実施
⎻ AWS Config⎻ Amazon Inspector⎻ AWS Trusted Advisor
✤ AWS環境の操作ログの取得⎻ AWS CloudTrail
✤ アプリケーションログの収集⎻ Amazon CloudWatch Logs
Leverage Many Storage Options
Leverage Many Storage Options✤ 万能なデータストアは存在しない
✤ データストアの特性(得意不得意)に応じて使い分ける
Leverage Many Storage Options✤ ストレージの使い分け
File/BlockStorage
ObjectStorage• ⾼可⽤• ⼤容量• 静的コンテン
ツ配信
• 低価格• アーカイブ
• NFS• 共有ディスク
• ⾼IOPS• 低レイテンシ• 永続化• 任意のファイルシ
ステム
Amazon S3 Amazon Glacier
Amazon EFS Amazon EBS
Leverage Many Storage Options✤ データベースの使い分け
Amazon DynamoDB
Amazon RDS
Amazon ElastiCache
Amazon Redshift
SQL
NoSQL• 低レイテンシ• インメモリ
• 3拠点間でのレプリケーション
• SSDに永続化
• トランザクション処理
• 汎⽤⽤途
• 集計・分析処理• ⼤容量データ• DWH
Leverage Many Storage Options✤静的コンテンツはS3に
✤セッションやステートはAmazon DynamoDBに
✤DBのキャッシュはAmazon ElastiCacheに
RDSDBInstanceActive(Multi-AZ)
Availability Zone
ELB
AmazonS3
AmazonCloudFrontUser
ElastiCache DynamoDB
WebInstances
AmazonRoute53
Implement Elasticity
Implement Elasticity✤ コンポーネントの正常性、可⽤性、固定されたロケーションを前提と
しない⎻ IPアドレスで参照しない、分散させるなど
✤ リブートや機能停⽌に対して弾⼒性のあるデザインを⾏う
✤ インスタンスのブートストラップ⎻ インスタンスが起動する時に、⾃分⾃⾝が誰で役割が何かを問い合わせる
✤ 動的な構成を優先する
Think Parallel
Think Parallel✤ 様々な並列アーキテクチャを試す
✤ クラウドサービスに対するマルチスレッドや並列リクエストの利⽤⎻ EMRを⽤いて並列のMapReduceジョブを実⾏⎻ ロードバランサ（ELB）を⽤いた負荷分散⎻ 1つのKinesis Streamと複数のKCLアプリケーション⎻ バックエンドとしてのLambdaの利⽤
Think Parallel: バッチ処理の例✤ 1インスタンスでN時間かけるのもN台を使って1時間で処理するのも
コストとしては同じ
Loose Coupling
Loose Coupling✤ 独⽴したコンポーネントを⽤いたアーキテクチャデザイン
⎻ コンポーネント間の結合度が緩やかになるほど、スケーラビリティは⾼まる
✤ すべてのコンポーネントをブラックボックスとしてデザイン⎻ 個々のリソースに固有の情報に依存しない
⎻ 必要な情報だけをわたし、API でアクセス⎻ IP アドレスではなく DNS 名でアクセス⎻ 処理を実施するインスタンスへの直接アクセスを避け、
ELB, SQS へアクセスさせるよう設計
✤ 負荷分散のためのクラスタ
Loose Coupling✤ キューを利⽤して疎結合なコンポーネント間でメッセージを受け渡し
密結合
キューを⽤いた疎結合
Component1 Component2 Component3
Component1 Component2 Component3
Q QQ
Loose Coupling✤ 結合度が緩やかになるほど、スケーラビリティは⾼まる
⎻ 独⽴したコンポーネント⎻ すべてのコンポーネントをブラックボックスとしてデザイン⎻ インタラクションの切り離し⎻ 独⾃で構築するよりも、冗⻑性とスケーラビリティが組み込まれているサービ
スを活⽤する
S3 Bucket
Lambda
Push: Event Notification
DynamoDB
Pull: DynamoDB Stream
Amazon Kinesis
Pull: DynamoDB Stream
SQS
messages
Get Message
InstancePut
MessageInstance
Amazon SNS Topic
Publish Notification
Queue Is Subscribed to Topic
Service Discovery
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
Asynchronous Integration
Asynchronous Integration ✤ 同期処理である必要がなければ⾮同期にする
⎻ その処理、本当にレスポンス必要ですか？
✤ ⾮同期処理の利点⎻ ユーザ側の利点
⎻ アプリケーションがブロックされない⎻ サーバ側の利点
⎻ スケーラブルかつ⾼可⽤なバックエンド⎻ Frontend を停⽌させることなく Backend を容易にメンテナンス可能⎻ 少ないFrontend のキャパシティで多くのリクエストを受付可能⎻ リクエストの処理順序やリトライ等の制御が容易に
Don’t Fear Constraints
Don’t Fear Constraints✤ より多くのメモリが必要？
⎻ 負荷を分散させる、キャッシュの利⽤を検討
Don’t Fear Constraints✤ より多くのメモリが必要？
⎻ 負荷を分散させる、キャッシュの利⽤を検討
✤ データベースにさらなるIOPSが必要？⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討⎻ PIOPS、SSDベースのインスタンスストレージ⎻ ElastiCacheを使ったデータベースのキャッシング
Don’t Fear Constraints✤ より多くのメモリが必要？
⎻ 負荷を分散させる、キャッシュの利⽤を検討
✤ データベースにさらなるIOPSが必要？⎻ 複数のリードレプリカ、シャーディング、DBクラスタを検討⎻ PIOPS、SSDベースのインスタンスストレージ⎻ ElastiCacheを使ったデータベースのキャッシング
✤ ハードウェア障害や設定が壊れてしまった⎻ シンプルに問題のあるインスタンスを破棄し、置き換える
The Twelve-Factor App
The Twelve-Factor App✤ 元はHerokuのエンジニアが公開したモダンなWebアプリケーション
開発のための⽅法論⎻ 直接的にクラウドと関連する話しではないが、少なくともWebエンジニアは⼀
読しておくべき
✤ Dockerによるアプリケーション開発やLambdaのようなサーバレスコンピュートの普及に伴い、改めて重要性が増しつつある
✤ URLhttp://12factor.net/http://12factor.net/ja/（⽇本語訳）
The Twelve-Factor App✤ Codebase - コードベース -
⎻ バージョン管理されている1つのコードベースと複数のデプロイ⎻ デプロイされているアプリとコードベースは常に1:1であるべき
✤ Dependencies - 依存関係 -⎻ 依存関係を明⽰的に宣⾔し分離する⎻ 特定の環境に暗黙的にインストールされているパッケージやツールに依存しな
いこと⎻ アプリケーションが必要とするツール、ライブラリはアプリケーションに同梱
されるべき
The Twelve-Factor App✤ Config - 設定 -
⎻ 環境によって異なる設定はOSレベルの環境変数によって注⼊されるべきである
✤ Backing services - バックエンドサービス -⎻ アプリケーションがネットワーク越しに利⽤するようなサービスはすべてリ
ソースとして扱う⎻ データベースやメッセージブローカーといったものはアタッチされたリソース
として扱う⎻ ローカル環境も本番もサードパーティもどれもリソースとして扱い、それらの
切り替えはリソースハンドルの切り替えとする
The Twelve-Factor App✤ Build, release, run - ビルド、リリース、実⾏ -
⎻ ビルド、リリース、実⾏の3つのステージを厳密に分離する⎻ それぞれのリリースは⼀意のIDを持つべき
✤ Process - プロセス -⎻ アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏す
る⎻ プロセス間で何も共有はしない⎻ 永続化する必要のあるデータはDBなどのステートフルな外部サービスを⽤いる⎻ ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとし
て扱い、永続化されることを期待しない
The Twelve-Factor App✤ Port binding - ポートバインディング -
⎻ ポートバインディングを通してサービスを公開する⎻ Webアプリケーション⾃体がサービスとなってリクエストを待ち受けること
⎻ リクエストを受け付ける何かを⽤意するのではなく、アプリに組み込まれるべき
✤ Concurrency - 並⾏性 -⎻ プロセスモデルによってスケールアウトする⎻ ⽔平⽅向へのプロセスのスケールアウトによって並⾏性を担保する
The Twelve-Factor App✤ Disposability - 廃棄容易性 -
⎻ ⾼速な起動と簡単な廃棄⎻ グレースフルシャットダウン
✤ Dev/prod parity - 開発/本番⼀致 -⎻ 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ⎻ CI/CDは各環境が揃っていることで実現される
✤ Log - ログ -⎻ 出⼒ストリームの保存先やルーティングには関与しない
⎻ ログファイルへの書き出しや管理などをアプリ側ですべきではない⎻ シンプルに標準出⼒に吐き出すだけ
⎻ 本番環境などではそれを集めて、保存し、インデックス化し分析する環境をアプリの外に⽤意する
✤ Admin processes - 管理プロセス -⎻ 管理タスクを1回限りのプロセスとして実⾏する
⽔平スケーリングを⾏うために⼼がけること✤ ステートレスアプリケーション/コンポーネント
⎻ ステートフルになる要素を⽔平スケールするリソースの外部に配置⎻ セッション情報は、DynamoDB/ElastiCache へ⎻ バイナリファイル, ログなどは、 Amazon S3 へ
✤ ステートフルになるコンポーネントをどう扱うか⎻ ⽔平スケールするマネージドサービスの利⽤⎻ ⽔平スケールができない場合に注意すべき制約を洗い出す
✤ 分散処理（今までのやり⽅を⾒直す）⎻ ⻑時間かかっていた単⼀のタスクを分割できないか検討
⎻ 1台のサーバで4時間かかるタスクを、4台のサーバで1時間でこなす
✤ 商⽤ライセンスの扱い⎻ ライセンスの提供元に確認
ステートレスにするためのセッション情報の扱い✤スケールアウト時
⎻ スケールアウトしたリソースが使われにくい
✤スケールイン時⎻ セッションも⼀緒に落とすことにな
るので、困難
Web/App
Auto Scaling
ELBClient
Web/App
Web/App
セッション 既存ユーザのセッションは、既存のコンポーネントにあるため、リクエストは、同じリソースへ
Sticky Session
スケールアウトしたリソースを活かしにくい
Web/App
Auto Scaling
ELBClient
Web/App
セッション インスタンスを削除すると、既存ユーザのセッション情報も失われてしまう(ログアウトされた挙動となる)
Sticky Session
ステートレスにするためのセッション情報の扱い✤ スケールさせやすくするためにセッション情報は外だし
Web/App
Auto Scaling
ELBClientWeb/App
DynamoDBセッション情報
ElastiCache
or
書き換えられても問題ない情報、肥⼤化の恐れがない情報はClient-Side で保持することも可能
Client-Side で書き換えられると困る情報はServer-Side で保持
各リソースに固有の情報がないので、いつでも増減しやすい
DevOps
Why DevOps?✤ ビジネスのスピードと多様性はより⼀層増している
⎻ 何が当たるかわからない⎻ 事業環境の変化⎻ 事前に予測しきるのは難しい⎻ 本当に求められているのは何なのか
✤ ビジネスを成功に導くためのITの重要性の⾼まり
Why DevOps?✤ ビジネスのスピードと多様性はより⼀層増している
⎻ 何が当たるかわからない⎻ 事業環境の変化⎻ 事前に予測しきるのは難しい⎻ 本当に求められているのは何なのか
✤ ビジネスを成功に導くためのITの重要性の⾼まり
素早い変化への対応が必要
What is DevOps?
What is DevOps?
⽂化Culture
実践Practice
ツールTool
What is DevOps?
⽂化Culture
実践Practice
ツールTool
What is DevOps?
⽂化Culture
✤ コラボレーション
✤ 壁をなくす⎻ チーム間⎻ 中間プロセス
✤ End to EndでOne teamであること
✤ 直接的に関係する個⼈に対する責任は減らす
✤ ⾏われた作業の結果に対する可視性を⾼める
What is DevOps?
実践Practice
✤ Automate Everything✤ Test Everything✤ 継続的インテグレーション
⎻ アプリケーションのテスト/QAは開発中ずっと⾏う
✤ 継続的デリバリ⎻ 環境をまたいだコードの⾃動デプロイ
✤ Infrastructure as Code✤ Canary, Blue-Green and Red-Black デプロイメ
ント✤ セルフサービスな環境
⎻ 調達ブロッカーをなくす✤ Microservices
⎻ 複雑なモノリシックアプリケーションを⼩さなものへブレイクダウン
Elastic Beanstalk
CloudFormationOpsWorks
⾃動化と構成管理✤ 宣⾔的なアプローチ
⎻ プロビジョニング⎻ 設定⎻ オーケストレーション⎻ レポーティング
CodeDeploy
継続的インテグレーション（CI）と継続的デリバリ（CD）
✤ 結果を事前定義し、コードの品質と機能を繰り返し検証する✤ 多様なツール群: ⾃社開発、オープンソース、プロプライエタリ製品、
SaaS✤ モニタリング、テスト、検証
AWSCodeDeploy
AWSCodePipeline
継続的インテグレーション（CI）と継続的デリバリ（CD）
✤ アプリケーションとインフラストラクチャの両⽅✤ 可能な限り⾃動化する✤ 宣⾔的にインフラを定義✤ セキュリティを含め注意深くインフラを設計✤ 定義や設定をアプリケーションコードのごとく扱う✤ バージョンコントロール✤ アプリケーションの⼀部としてのインフラ✤ ロールバックのためのプラン✤ モニタリング、ロギングと監査
Introduction to MicroservicesDevOps and AWS
VersionControl
Build/CompileCode
Dev
UnitTestAppCode
ITOps ENV
DR
Test
Prod
Dev
Application
WriteAppCode
Infrastructure
AWSCloudFormation
tar,war,zipyum,rpmDeploy
AppPackage
Application
BuildAMIs
ValidateTemplates
WriteInfraCode
DeployInfras
AutomateDeployment
ArtifactRepository
Onlydeploysapplication
Onlydeploysinfrastructure
AWSCodeDeploy
CI/CDと⾃動化
What is DevOps?
ツールTool
✤ ⾃動化とCI/CDのためのツール⎻ Pipeline管理ツール⎻ ソースコード管理ツール⎻ テストフレームワーク/テストツール⎻ コードレビュー/フィードバックツール⎻ コードの静的解析ツール⎻ デプロイツール
✤ ⼀貫性のある、予測可能なアプリケーション管理と設定管理
✤ インフラストラクチャの計測⎻ メトリクス⎻ ロギング⎻ モニタリング⎻ APM(Application Performance Monitoring)
✤ セキュリティの分析と管理ツール
What is DevOps?
DevOps =
開発者 顧客
releasetestbuild
plan monitor
デリバリのパイプライン
フィードバックループ
ソフトウェア開発のライフサイクル
無駄やボトルネックを取り除くことで、ライフサイクルを効率化し、⾼速化すること
DevOps Tools on AWS
Networking AnalyticsCompute
Storage & Content Delivery
Developer Tools Management Tools
Security & Identity
Mobile Services Database Business Productivity,Desktop & App Streaming
S3 CloudFront EFS Glacier StorageGateway
AppStream
CloudSearch
SES SQS
Mobile Analytics
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
CodeCommitCloudWatch Cloud
FormationCloudTrail Config OpsWorks Service C
atalog
IAM DirectoryService
Trusted Advisor
WAFSnowball
DMS
IoT
Io T
Game Dev
Mobile Hub
Elastic Beanstalk
ACM Inspector
GameLift
CodePipelineCodeDeploy
ほとんどのサービスに⽤意されたAPILightsail AWSBatch
ApplicationDiscoveryService
SMS
Pinpoint
Application Services
API Gateway Elastic Transcoder SWF StepFunctions
Messaging
Migration
X-RayCodeBuild
AmazonLex AmazonPollyAI
LexPolly Rekognition MachineLearning
KMS ShieldOrganizations
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
オンプレミス新しいインフラの構築は複雑かつ遅くなりがち
クラウドワンクリックで新しい
インフラを⽤意
新しいデプロイ環境を構築
新しいテスト環境を構築
新しい環境を海外に構築
1,000 サーバ追加
1,000 サーバ削除
必要 調査 評価
計画 設計 エンジニア
調達 契約 コミッション
デプロイ
MonitorProvisionDeployTestBuildCode
Elastic Beanstalk
OpsWorks
CloudWatch
CloudFormation
CodeDeploy
CodeCommit
CodeBuild
AWS DevOps Services
CodePipeline
ThirdPartyTools
Jenkinsを使ったデプロイ✤ 多くのプラグインが利⽤可能
✤ CIとCDに使われている
✤ CodePipelineからの呼び出しが可能
✤ GitHubのWebHookによるイベント受信
✤ Dockerイメージをデプロイするプラグインも利⽤可能
JenkinsとDockerを使った継続的デリバリ
Introduction to MicroservicesDevOps and AWS
Bucket AmazonECS
AWSCloudFormation
ECSCluster
コンテナのメリット
PortableFlexibleFastEfficient
Server
Guest OS
Bins/Libs Bins/Libs
App2App1
Dockerの特徴
PackageShipRun
Cluster Management
$ docker run myimage
Server
Guest OS
Bins/Libs Bins/Libs
App2App1
Amazon EC2 Container Service (ECS)
✤ 管理ノード不要の、安定かつ⾼パフォーマンスなクラスタ管理サービス
✤ Dockerコンテナを複数のEC2インスタンスに分散配置
✤ ⼀時的な計算処理にも、ロングランニングな処理にも対応
✤ ELB連携など各種AWSサービスとの親和性
✤ Amazon ECS⾃体の利⽤は無料
複数のコンテナをEC2のクラスタ上で⼀元管理できるサービス
その他のベストプラクティス✤ CI/CDは必須
⎻ 頻繁なコミットとコミットごとのビルド⎻ 実際に稼働する環境を⽤いたテスト
✤ コードのすべてをコードリポジトリに保管⎻ アプリ、インフラ、ドキュメント⎻ リポジトリ上にないものはプロダクションに持っていってはいけない
✤ コードレビューは良いコードのためのベストな⽅法⎻ クリーンで誰もが理解できるコードか？⎻ 設計がニーズを満たせているか？⎻ 同じことをするのにより良い⽅法、簡単な⽅法はないか？
その他のベストプラクティス✤ ⾃動ロールバック
⎻ 失敗時における最も速いリカバリのメカニズムと⾔える⎻ まずはロールバックし、その後ログ/グラフなどを⽤いてデバッグする
✤ ダッシュボードを通じて状況を把握する⎻ 今何がおきているか？⎻ 通常時はどのように⾒えているのか？⎻ グラフがおかしかったり、アラームが発⽣した場合に何をするのか？⎻ グラフ内の動きはどのようなイベントと紐付けられるのか？
Conclusion✤ クラウドを最⼤限に活かすには、アプリケーションをスケーラブルに
作ること
✤ スケーラブルなアプリケーションを作るための⽅法論はいくつかあり、適宜⾃分たちにあわせて選択をしていくこと
✤ 忘れちゃいけないDevOps⎻ というかCIとCD⎻ すべてを頻度⾼くテストする
