inokappa/aws_summit_2017_dev_day.md

## aws_summit_2017_dev_day.md

      
    Raw
  

              aws_summit_2017_dev_day.md
            
          
    DevSecOps on AWS - Policy in Code

URL


http://www.awssummit.tokyo/devday/index.html#D3T7-2

ターゲット


AWS を既に利用している

memo


DevOps ... ソフトウェア開発のライフサイクル
デリバリのパイプライン build => test => release
フィードバック plan <= monitor
DevSecOps
Security and Compliance
iso27001
Plan
Do
Check
Act
Security Automation
Security Contorol
Proactive Monitoring
Security ad Scale Infrastructure as a code
Security Control
IAM
権限コントロール
導入しやすい
Assume Role
クロスアカウント(IAM Role & STS)
アカウント A とアカウント B で信頼関係が必要になる
Assume Role を利用すると一時的に有効なクレデンシャルを発行してくれる
AssumeRole によるクレデンシャルの生成（Python）
IAM によるタグ管理 - Tag on Creation
aws:RequestTag/CostCenter
git-secrets を使ったクレデンシャルの管理
git secrets --scan
git commit 時にチェックしてコミットさせない
Proactive Monitoring
AWS CloudTrail
AWS CloudWatch
AWS Config / Config rules
Security ad Scale Infrastructure as a code
CloudFormation でデプロイする
BaseLine
IAM
Proactive Monitoring
pyflakes でチェック
まとめ
Security Automation が実現可能
Security Baseline = Dev + Ops + Sec
Code
CloudTrail Remediation

[メルカリ] Cloud connect the world as a Glue

Speaker


@kazeburo

SRE Team


Site Reliability Engineering
ソフトウェアエンジニアリングによりサイトサービスの信頼性を向上する
Mercari SRE「信頼性の高い」サービスの実現
インフラよりもサービス指向

メルカリ


国内最大級のフリマアプリ（泣く子も黙る）
6500 万 DL
1200 品/min の出品数
グローバル展開（US/UK/JP）
サンフランシスコ、ロンドンにエンジニア

Global Development のススメ方


太平洋、大西洋をまたいだ Pull Request のレビュー
Slack
Video カンファレンス
リモートペアプロ
週一で SyncMTG
UK とは案件ベースで MTG

メルカリのインフラストラクチャ


JP sakura インターネットで物理サーバー
VPS 1 台で 2013/07 に開始（Web + DB）=> sakura cloud
Nginx で Revers Proxy
DNS Round Robin
Search は Solr
Database は ioMemory / NVMe
US Amazon Oregon
UK GCP
サーバー中心の Architecture
Ansible Playbook
JP で実績ある構成
3 つのリージョン
クラウドらしい設計はせず、運用の共通化と省力化

Mercari Global Infrastructure


データをサービスを行う域内で留める必要がある（UK）
クラウドの高いスケーラビリティ
Route53
Akamai / CF
共通の Micro Service
Analyze: Google BigQuery
Storage Amazon S3

Amazon Route53


Roadworker を利用
Routefile を Github で管理
Pull Request を merge した後で Travis で CI して Route53 に適用
Helth Check を利用することで可用性を高めることが出来る

内部 DNS


全てのサーバーに unbound を導入している
ローカルキャッシュによるパフォーマンスの向上
consul も利用している
アプリケーションからの接続は CNAME を経由
移行を考慮

Amazon S3


商品画像、ログ、データベースバックアップを保存
商品画像: 数百万枚/day
ログ: 1TB/day
batch + aws-cli
データベース: 1.2TB /day
S3 をシステム連携の Hub として利用する（Amazon S3 as a Hub）

機械学習


サービスで利用中、検証中
検索結果の改善
出品時に価格サジェスト

距離を超えて世界をつなぐ


光は 50msec に地球半周は出来ない = 遠距離との通信コストは高い
石狩遠い問題

高レイテンシ環境での HTTPS 通信


RTT 26msec で HTTPS 通信を行った場合に 200msec 以上かかる

クライアントからの接続改善


CDN を利用する
クライアントは近くにある CDN のエッジサーバーと TLS Handshaking
mercari.com はパスでルートを分けている

アプリケーションからクラウドへアクセス


アプリケーションで HTTPS 通信の KeepAlive を行う
PHP で keepAlive は難しい
Chocon
Go で実装した proxy server
似た middleware は見つからない
単純な forward proxy だと HTTPS 通信の集約は出来ない
HTTPS は end to end で暗号化
Chocon を使うことで RTT が 90msec から 19msec に改善

[Intelligence] オンプレから移行するので、Amazon ECS でコンテナ化と Terraform でインフラコード化した話(On-Prmise to AWS)

URL


http://www.awssummit.tokyo/summit/index.html#D3T5-6

誰


Intelligence

HITO Manager


アルバイト採用管理システム

なぜ AWS に


ビジネス背景
HR x Tach 業界の競争激化
スピードアップの必要が高まる
課題
子会社まかせ
レガシーインフラ
大量の技術負債(CentOS 5.x)
変化に対応出来ない
脱子会社
レガシーインフラ
設定がブラックボックス化
構成変更申請が面倒
トラブルの原因追求が打ち切られる
グループ共通のオンプレ基盤の為、改善が困難
脱・レガシーインフラ
設計を透明に
構成変更を柔軟カツ高速に

どのように移行したのか？

構成管理


構成管理無し
設計書無し => Terraform に移行
Terraform の module を活用
Terraform のバージョンアップ頻度が高い
plan と apply で結果が異なる

LB


従来は BIG-IP
負荷分散が出来ていない...
ALB に移行
ALB
ECS との親和性が高い
Nginx
リバースプロキシとして利用
ALB をカジュアルにいじりたくない

アプリケーション


ECS
コンテナ化
依存関係を分離
Blue Green Deployment

Database


Aurora に移行
Aurora の Audit ログに対応したので RDS MySQL から移行した
MySQL 差分インポート機能

モニタリング


Hinemos がオオカミ少年化していた
まかれる + fluentd + Slack

NFS


Amazon S3 + Goofys
S3 を Goofys で NAS 化

移行してどうだったか


小さく素早く
段階的な移行
1 次移行
Route53 に移行
nginx によるオンプレと AWS への振り分け
2 次移行
DB 移行がネックだった
1 つのバッチが移行漏れ
延期した
切り戻しのラインは明確に定めておく
移行して良かった！