AWSがもたらす ... - Amazon Web Services · Title: AWS Summit Author: Microsoft Office ユーザー Created Date: 6/16/2016 2:58:43 PM

AWSがもたらすエンタープライズにおけるQCDの実現

キヤノン映像事務機DS開発センター

八木田隆Canon Inc. Copyright 2016 All rights reserved.

ブラウザスマートフォンデバイス

Hosting Cloud

collect analyze biz authorization

authenticationformprint

Canon Inc. Copyright 2016 All rights reserved.

成果全体

リリース年３回 → 週に複数回インシデント 1/5脆弱性診断指摘： 1/4

Print Service

コード量 1/5

スループット 2

運用コスト 1/5

インフラコスト 1/4

評価工数 1/4

開発期間 1/3(６ヶ月)


課題• 仕事に集中できない

• システムやインフラの制約が不明瞭– インフラ問題や障害に付き合ってる時間が長い

– スケーリングしない、フェールオーバしない

• 安定させるためのチューニングに時間かかる

• ホスティング業者との打ち合わせが長い

• リリース作業に時間がかかる• リリースコストが非常に高い

• 年３回のアップデートがやっと


• 自動化をやりきれない• API制御が部分的

• 自動化するコストも膨大

• 監視、管理しにくい• 取得できないログが大量

• ログも煩雑で漏れが発生

QCDQuality

品質、安定性、セキュリティ、機能性・・・

Cost

低コスト、工数、インフラ・・・

Delivery

Agility、リリースの早さ、リリースの多さ


AWSのイノベーション


我々が注目したのは「APIによるコミュニケーション」

AWSは全てがAPIでありAPIで全てを制御


考察AWSを紐解く

APIによるコミュニケーション


クラウドの本質はAPI

認証認可対象操作

OOP DDD Microservices Team

Object Domain Microservice Team

API


Point

Resource責務

コミュニケーション

Action

認証認可対象操作

Security

JSON

API


ROA resource oriented architectureAWSのResource/API設計が素晴らしい

CloudFormation

Simple


• オープンな標準技術に忠実

• 設計思想に一貫性がある

使いやすい & 連携しやすい


のDesignについて

複雑さとの戦い

イノベーション

本来やるべき仕事に集中する


施策

API自働化

Communication

Security

Architecture

MeasurementCanon Inc. Copyright 2016 All rights reserved.

シンプル思考

EngineerはEngineeringで課題を解決する

２つのMotivation

「使いこなす」カタログエンジニアになるな機械に使われるのではなく、

機械を使いこなすのではなければならない


最優先事項

セキュリティ


AWS Securityセキュリティが最優先事項！


仮説

• セキュリティレベルの高いAWS

• 責任共有モデル

• アプリケーションがAWSと連携し高セキュリティを実現すれば・・・

API


AAA ModelSPA

全てのアクセスを一元管理/一貫性管理

Authentication(認証)Authorization(認可）Accounting(アカウンティング)


3 Tire ・ Cloud Native

API

AAA

IAM

IAMによる融合


White Hacker

設計段階からの連携

ペネトレーションテスト

ハッキングテスト

良好な診断結果

API

AAA

IAM

Hostingシステムよりも


ARCHITECTURE


クラウドエンジニアの養成

CAP定理

at least once

exponential backoff

結果整合性

冪等性

Design for Failure

DNS / timeouthttp://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

QoSScalability

CAP定理

Infrastructure分散システムDynamo論文


Serviceteam

Serviceteam

Serviceteam

Serviceteam

Architect

Op

s team

QA

team

役職や年齢関係なく選出

Professionalservice

EnterpriseSupport


疎結合 & SIMPLE

Cloud NativeMicroservice3 Tire


基準

アーキテクチャー基準セキュリティ基準マルチテナンシー基準API基準モニタリング基準ロギング基準Alert基準


自働化


自働化の目標• 開発〜サービス運用・監視までをカバーする

• Dev+QA+Dev+Secが連携できる

• 継続的インテグレーション

• 各部門が本来やるべき仕事に集中できる

• Testabilityを高める

• 開発〜リリースまで時間短縮する

• 品質を作りこめる


CI Platform

Automated infrastructureShared version controlOne step build and deployShared metricsAlert BotTDD

DevOps視点


Dev QA Sec Ops User

Testability

Measurement Log Metrics Alert

自働化

CI


frontend

application

datastore

縦の関係

(Su

bn

et)

横の関係 (SecurityGroup)

Trial

Stack

Test

Stack

Penetration

Stack

Rehearsal

Stack

presentation

NACL

InboundOutbound

NACL

InboundOutbound

NACL

InboundOutbound

NACL

InboundOutbound

Enterprise Testability

Immutable作成したStackに変更は加えない

Devphase

QAphase

Secphase

Opsphase

複数の部門が同時進行1チームが開発〜リリースまで出来れば良いのだが

security group A

同一性の担保SecurityGroupの設定だけが異なるStack

security group B security group C


StatelessStack Blue-Green Deployment

Stateless Stack Stateful Stack

(Immutable Stack)


replication

StatefulStack Blue-Green Deployment(Immutable Stack)

Stateful Stack

Stateless Stack


Merit Immutable Stack

• All Green Stackそのものが本番で稼働– 本番環境一発勝負的なものを無くす– CloudFormationのTemplate検証

• Disposable– ウィルス感染などしてもStackごと捨てられる– Rollbackしやすい

• Simple– オペレーションがシンプルになりミスが減る– 問題点も明確になり対策が楽になる


自働化について

自働化の構築が容易

全てをAPI制御


Communication


APIによるコミュニケーション

Microservice Team

APIAPI


Focus何に注力するか

Simple無駄の排除

Concentration

チームが本来やるべき仕事に集中


{"AWSTemplateFormatVersion": "2010-09-09","Resources": {"WebGroup" : {

"Type" : "AWS::EC2::SecurityGroup","Properties" : {

"GroupDescription" : "Enable HTTP access via port 80","SecurityGroupIngress": [{"IpProtocol" : "tcp","CidrIp" : "0.0.0.0/0","FromPort" : "80", "ToPort" : "80"

}]}

},"WebServer" : {

"Type" : "AWS::EC2::Instance","Properties" : {

"ImageId" : "ami-xxxxxxxx","InstanceType" : "t1.micro","SecurityGroupIds" : [{ "Ref" : "WebGroup" }

]}

}}

}

Templateによるコミュニケーション

template

開発運用

CloudFormation

基準アーキテクチャー基準セキュリティ基準・・・


MEASUREMENT


意思決定はデータに基づいて行う

「現実世界の現象を元に自律的思考、意思決定を促す」

「問題をきちんと述べられれば、半分解けたようなものだ」

「全員が同じ事実を共有できるようにデータを見せる」

計測できるものは改善できる by ピアソンの法則

計測できるものは管理できる by ドラッカー


全てをAPIで制御できれば効果的なMEASUREMENTが可能

API化できればログ、データが取得でき

網羅的に効果的な管理、監視、監査、通知が可能


API

Log Data

見える化

インフラ

アプリケーション

AP

I

CloudWatch

alarmAWS

CloudTrailAWS

ConfigAWS Trusted

Advisor

kibana

TRENDmicro

AppScan

監視データ化管理メトリクス Alert

ZABBIX

fluentd


Daily Meeting整理すれば、課題が見える課題が見えれば、ヒトは自立的に動くデータを示すことで、現場のが自ら気づき問題意識を高め、自ら改善する


まとめ


成果全体

リリース年３回 → 週に複数回インシデント 1/5脆弱性診断指摘： 1/4

Print Service

コード量 1/5

スループット 2

運用コスト 1/5

インフラコスト 1/4

評価工数 1/4

開発期間 1/3(６ヶ月)


EngineerはEngineeringで課題を解決する「使いこなす」

API


KAIZEN

より高いQCDの実現に向け

• Dev+QA+Ops+Secの融合

• Simple Communicationの推進

• Microservice化の推進

• Testabilityの向上

• Measurementの向上

• Deploy回数の向上(Kaizenの証)


Innovation

Concentration

Simple

Dev QA Sec Ops

Focus

Kaizenヒトが元気になった

やるべきことが明確

成果が見えるようになり


Engineerが元気になる


Documents

AWSがもたらす ... - Amazon Web Services · Title: AWS Summit Author: Microsoft Office ユーザー Created Date: 6/16/2016 2:58:43 PM