AWS Summit Osaka 2019

# AWS Summit Osaka 2019
https://aws.amazon.com/jp/summits/osaka-2019/

# 基調講演
## スピーカー 代表取締役社長 長崎忠雄

- 大阪開催は今年初めて

### AWSについて
20ヶ国30箇所以上
リージョン:21
AZ:66
東京は4つ
エッジロケーション(CloudFront CDN):150以上


### ビジネスアップデート
年間成長率41%
2004年は24の機能拡張しかできなかったが、
2019年は1957の機能拡張
現在はトータルすると4000以上の機能拡張

サービス:165以上

### 顧客
Slack等

全体のクラウド利用の1/2はAWS

- 国内
 - 金融:みずほ
 - 大阪ガス（家庭用燃料電池）
 - 毎日放送 オンデマンドをLambdaで実現

- 海外
 - 金融:キャピタルワン


- 地球上で最もお客様を大切にする企業
 - 過去72回の値下げ


### クラウドジャーニー
=エンタープライズにおいてクラウドの利用はまさに旅であると表現できる

- 移行して終わりではなく、それから有機的に色々繋がっていく
 - オンプレ=資産
 - システム安定性とデータの完全性を守りつつ移行する
 - まずはLift & Shift。それが終わった後によりクラウドネイティブなアプリ開発など拡張できる

- 1.計画
費用面、運用効率、セキュリティ、パフォーマンスの観点からAWSの検証を行う
従来のやり方ではだめ
使ってみて実際にどうだったかが重要
キャパシティプランニング

↓一部移行後

- 2.ハイブリッド
社内でクラウド人材を育成
運用の自動化を検討しながら、実装

- 3.拡張と最適化
コストは下がるが、スピードが加速するかが重要
自動化=人が介在する事によるミスを減らす

- 4.クラウドファースト
社内に立証される


### 企業の移行の課題は2つ
- DBとWindows
- DB
 - 商用データベースが顧客のニーズに合わなくなってきてる
 - データがペタバイトクラスに増え、今後も増えていく
 - msec以下ののレイテンシが要求される
 - AWSで特定の用途にあったDBの選定
 - AWSは15のDBサービス
 - リレーショナル/キーバリュー/ドキュメント/インメモリ/グラフ時系列/QLDB
 - Amazon Redshift データウェアハウス
   現在では平均で顧客の87％がRedshiftでの処理で大きな待ち時間を経験しなくなった（1min以下)
 - 残りの13%は Amazon RedshiftConcurrensy Scaling
   10分以上の待ち時間を解消した
   数千に及ぶクエリの同時実行

- Windows
特殊な設定なくすぐに使える


### VMware Cloud on AWS
- VMwareと共同開発
- 東京リージョンで利用可能

A.データセンタ拡張
B.ディザスタ
C.クラウド移行できるものから移行


### 最新テクノロジー
- SageMaker
- これらは作りたくて作ったわけでは無く、お客様の要望に答えただけ


### AWSのミッション
- 全ての開発者に機械学習を
- AIサービス
 - 画像&映像
 - 言語
 - 対話

- 2つの新サービス
 - 予測
   Forecast
   時系列の予測サービス
 - リコメンデーション
   Personalize
   過去の購買データを元に
   利用事例Domino's Piza

- 機械学習サービス
 - Amazon SageMaker
 - 開発 学習 推論


### DeepRacer
- 機械学習で走る
- 仮想レースでスピードを競う



## スピーカー 京セラ株式会社 経営管理本部 経営情報システム部 副部長　藤田 正則 氏
### 基幹システムの移行
- アメーバ経営
- 30年以上前のソースがベース
- 老朽化
- COBOL->JAVA

### AWSの採用理由
- グループ展開を想定して、グローバルに対応できるように
- インフラ管理手法 IaS
- OSS活用コスト柔軟性俊敏性

### システム構成ず
オンプレのまま移行できない部分との通信はAWS Direct Connectで繋いでる


### よかった事
- 構築自動化
 - 開発1/検証2/本番1 環境の予定だったっが
   開発1/検証8/本番1 環境が急遽必要になった

- 自由度
 - Amazon Database Migration Service

### 今後の方針
SoR 基幹系システム
SoE ユーザーと企業をつなぐシステム
SoI 情報分析活用の取り組みを推進




## スピーカー 株式会社ヌーラボ 代表取締役　橋本 正徳 氏
- backlog
- cacoo ビジュアルコラボレーションツール
- typetalk チャットツール

### cacoo
- 中心サービス
- 日本以外でもグローバルに利用されてる
- 全体300万人の内、海外シェア率86%

- インターナショナルな開発チーム
 - 2009年は2人だけだったが、今はNewyork、アムステルダムと開発人数がグローバルに増えてる

- モノシリックなソフトウェア構造とグローバルな組織のミスマッチ

- 解決方法としてのマイクロサービス化
 - 機能毎に開発拠点で分けた
 - ビルド、デプロイを機能毎に行う
 - kubanetesを採用


- 現在、backlogもマイクロサービス化を検討
 - kubanetesの課題
   バージョンアップが頻繁
 - AWS EKSで解決
   管理不要
   難しい部分を考えなくていい
   アップデートもよしなにしてくれる








----
#  SESSION
## スピーカー アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 福井 厚

### クラウドネイティブなモダンアプリケーション開発入門
### マイクロサービス
- CI/CD

### モダンアプリケーション開発
- WHY
 - アプリケーション開発の速度
 - 実験でイノベーションを加速
 - Amazonフライホイール効果
 - 2017年:1430の新機能、サービス

### 移行パターン
- Re-host
- Re-platform
- Re-architecture
- Re-invent

### ライフサイクルをセキュアに
- 自動化されたセキュリティ評価
- セキュリティオートメーション ツールボックス

### マイクロサービスの集まりにする
- 全てというわけではない
- 変更の影響を小さくする
- APIと疎結合なコミュニケーション
- ワークフローで複数を連携

### 可能な限りサーバーレス
- 自動化と抽象化でインフラのプロビジョニングや管理が不要
- 最小の努力で最大のアジリティを提供
 - 付加価値を生まない作業は自動化すべき

### IaS
インフラのデプロイスピードとアジリティを向上

- Cloud Development Kit
プログラミング言語(python,typescript等)でインフラを構築

### CI/CD
- AWS CodePipeline
 - コードプッシュからデプロイまで完結

### モニタリング
- マイクロサービスはログが分散する
CloudWatchで一元管理

- AWS X-Ray
分散アプリケーションの性能のボトルネックを特定


### モダンアプリケーションの実装パターン アーキテクチャパターン
- APIGatewayパターン
デバイスやブラウザ毎にリクエストを分ける
 - Amazon API Gatewayを利用
   スロットリング
   キャッシュ
   認証

- サービスディスカバリ
 - 複数のサービス間の呼び出し連携
  - Cloud Map

- サーキットブレーカーパターン
共倒れを防ぐ

- コマンドクエリ責務分離パターン(CQRS)

- イベントソーシングパターン
直にUPDATE流さずに状態更新をキューイング
Kinesis

- コレオグラフィ
- オーケストレーション
親子関係のサービス

- 集約ログパターン
各サービスのログを一括集約

- polyglotパーシステンス
データソースは何でもいい





### CI/CDパターン
- シングルページアプリケーションの場合(S3のパブリック公開機能でCloudFrontでキャッシュ)
- AWS Amplify Console
 - CI/CDのパイプラインを作る
 - pushするとクライアント/バックエンドへビルド

### コンテナへのデプロイ
AWS CodePipeline




## クラウドへシステムをマイグレーションするときの整理指針

### スピーカー アマゾン ウェブ サービス ジャパン株式会社 Product Marketing エバンジェリスト 亀田 治伸

### オンプレからクラウドへの移行
世界で$1.25Tに到達

### AWSのセキュリティの考え方
- 責任共有モデル


- 1.What
対象システム
費用対効果と難易度が比例してる
いきなりクリティカルなところから手をつけるのはお勧めできない
社内にノウハウを貯めていく

- 2.Why
これ大事
業務の生産性
コスト削減だけでは…
浮いたコストをエンジニアのモチベーションに
基本はクラウドは移行は大変で、その後が重要

- 3.How
戦略
 - 1.Re-Host
既存環境をそのアーキテクチャのまま移行
これが一番おすすめ
これやってからAMIコピー作って色々やっていく

 - 2.Re-Platform
どうせならバージョンアップと共にやる

 - 3.Re-Purchase
クラウド対応したライセンスまたはアプリケーションに買い換える
規模が大きければ大きいほど自前で持ってったほうが安い

 - 4.Re-Refactor
クラウド環に最適化
アプリケーションを書き換え
これが一番難易度高くてコスト効率が高い

 - 5.Retire

 - 6.Retain
オンプレを引き続き使用する
例えば金融ノンストップサービス
役員の説得コストがかかるので


古いアプリケーションのエンジニアはいらないので、
どこかで塩漬けを解除しておかないと移行できない状況になってしまう。


### EC2
仮想化マシン=インスタンス

- インスタンスタイプ
143種類
通常はMかT

 - T
特殊汎用
Mより安いが、若干特殊な制限
CPUバーストクレジット
暇なときにCPUリソースをアカウントに蓄積
CPUキャパ（能力）を超えてCPU使ってくれる
うまく使うと費用対効果あるが、それに慣れていないとおすすめできない
特性を把握した上で使う

- C
CPU最適化
メモリに対してCPUが多く設定
通常より

- R
Cの逆
メモリ最適化
よりメモリが必要な時

- H1/I3/D2
ストレージ最適化
Hadoopなど、データ解析に向いてる

- ベアメタル
仮想化では動かないアプリケーション用

- インスタンスのライフサイクル
 - 一時停止 インスタンスを削除しない
課金を下げるための一時停止時やインスタンスタイプの変更時


- インスタンスのユーザーデータ
起動時に渡すことができる
 - Linuxの場合
cloud-init


- インスタンスメタデータ
https://IP/latst/meta-data/
全てのメタデータがテキストとして返される


### EBS
- 汎用 SSD
 - gp2
容量が増えるほどストレージが早い
小さいストレージの場合は思ったより遅い可能性

 - プロビジョンド SSD
通信固定

- EBSを当てないEC2
EC2インスタンスストア内にストレージ
シャットダウン時にデータが消える
 - ユースケース
一時的な計算やバッチ処理をさせる場合はあえてEBSをアタッチせずにEC2のみを起動する
10万IOPS実現したい場合

- スナップショット
2世代目のみを消してもAWSがいい感じに差分から1,3世代目を作ってくれる

- EBS最適化
特に理由がない限りこれを使う


### VPC
ネットワーク空間
↓
Public or Private
↓
経路
↓
in/out


### テナントタイプ
- 共通インスタンス
一般的にはこれ
他顧客と共同

- 占有
1社がCPU使うと他者に影響が及ぶので、それが許容できない時
物理ではない

- Dedicated Host
占有の物理版
BYOL可能


### 165を超えるサービス
マネージドサービス
アプリケーション以外のものをAWSヘ

- いいとこ
ミドルウエアパッチ、冗長構成を考えなくていい

- 悪いところ
OSにアクセスできない


### ストレージ
複数のEC2から1つのストレージを見ることができるようになった


### 移行支援
ツール実行してみてどこまで自動化で作業ができるのかを把握してから、どれを使うかを検討

- AWS SMS
無償
VMWare,Hyper-Vの仮想マシンを移行

- Cloud Endure
VMWare,Hyper-Vをすいとる
環境に依存せず、仮想化以外にも使える

- AWS DMS
オンプレのDBからデータを吸い取る
スキーマコンバージョンツール




## クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織
### スピーカー 株式会社ヌーラボ 木村 幸平 、 吉岩 祐貴

### クラウドネイティブ
kubernetes
スケーラブルなアプリケーション構築および実行する技術の総称
コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ等

### メリット
- 回復性
 - アプリケーションが落ちても新しく立ち上げてくれる
- 管理のしやすさ
- 可観測性
アプリケーションの状態を見れる状態にする

### Trail Map
- 1.コンテナ化
インフラを疎結合に

- 2.CI/CD
テスト、ビルド、デプロイ自動化

- 3.オーケストレーション
Kubarnetes


### 複数のホストを抽象化
ホストマシンはマシンリソースのプール


### 流れ
EC2の上にアプリケーション
新機能は別サービスで
既存機能は切り出してDockernize
↓
Amazon ECSへ移行
↓
Kubernetes
↓
依存関係が減った


## Kubanetesが必要なケース
複数拠点開発
インフラスケーリング
ビジネス要求への対応


### CacooみたいにBacklogもK8sにしたい
アプリケーションからgRPCで通信
EC2インスタンスは200くらい
Terraform+Ansibleでインフラ運用

- 運用上の問題と開発上の課題を解決するために
 - EKS
IAMと密に連携してる

- なぜEKS
CacooがK8sの管理に苦労してた

- なぜECS Clusterではないのか
チャレンジ精神

- EKSで何やってるか
新機能のドッグフーディング

- 課題
モノシリックな現サービスを今後どうするかは検討中

- 運用はどう変わるか
EKSの運用管理はTerraform
コンテナに割り当てるIAMもTerraform

### Worker Nodeの作成
AWS公式のWorker Nodeテンプレートを使用



## クラウド流 移行プロジェクトの進め方
### スピーカー アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 コンサルタント 松本 雅博

### 目的
何から移行するか
- POCの実施
 - まず簡単なものから
 - 難しいものもあえてPOC→課題感を得る
 - POCの失敗は悪いことではない

- KPI設定
リリース頻度が月○回に増える
移行後の評価
継続的な最適化


### 2つのアプローチ
クラウドネイティブ
リフト&シフト


### 移行実施方法
- 1.分け方を決める
- 2.移行順序を決める
- 3.移行方式

サーバ台数が数十台なら一度に移行はできない

### 分け方を決める

### 移行順序を決める
- リスクの低いものからだと
 -  リスクヘッジ優先
- ビジネス効果が大きいものからだと
 - ますはビジネスメリットを得れる


### 移行方式
6R

### 移行先の設計指針

### Cloud Adoption Framework
ビジネス観点でまとめたフレームワーク

### Well Archtected Framework
165のサービス

### 実施
サーバ移行
データベース移行
データ移行

## 移行関連サービス
- SMS

- DB
ダウンタイムを最小限に
異種プラットフォームの移行も可能

- DataSync
オンプレからエージェントを介して移行

- Snowball/Snowball Edge
回線に依存しない移行が可能

- 評価
KPIを元に評価

- Lift & Shiftが終わったら
クラウド最適化


### クラウド移行によってえれるもの
- オンプレミスは机上でのチェックが多いが
- クラウドは制約から解放される
とにかく実験を繰り返せる

- 作りながら要件と設計を固める
机上ではやれない、まずは触る

## 推測ではなく、実測
机上での検討ではなく、実際に試す

現実的な目標復旧時間(RTO)

通常時は機能テストが実施できる最小限のリソース
休日は開発環境を停止
調査時に開発用のインスタンスを即座に立ち上げることができる


### IaS
インフラをソースコードと同じように扱う
より実験しやすい仕組み作り
手作業からの解放




----
## Night School
### スピーカー アマゾン ウェブ サービス ジャパン株式会社 Product Marketing エバンジェリスト 亀田 治伸
AWSはサービスが多過ぎる
利用料金内訳 約70%がEC2


### Billing Alert(請求アラーム)
自動化と制御を行うことができる


### リージョンとAZ
大阪は1つのローカルリージョン

- AZ
1つ以上のデータセンター群
- リージョン
2つ以上のAZから構成

- もし東京リージョン全体がダウンした場合
別リージョンを使う
もしくは、AWS以外のサービスも使えない可能性があるのでそこをどこまで考慮しておくか

### EC2
サイズ変更可能なコンピューティング
支払いは実際に使用したキャパ分のみ

- 起動プロセス
 - 1.リージョン決定
 - 2.AMIから起動
 - 3.インスタンスタイプを選択（CPU、メモリ、ストレージ、ネットワーク要件）
 - 4.IP、セキュリティグループ

- AMI
AMIを起動した後にアプリケーションインストール後に作っておくことができる
全アカウント共有
特定アカウント共有

- EC2に直接ストレージを持たせることも可能

- インスタンスタイプ
100を超える

 - c3.8xlargeの場合
   c インスタンスファミリー
   3 世代。こだわりがなければ大きいものを選ぶことでコスト効率がいいもの
   8xlarge サイズ


### EBS
- スナップショットの見積もりはややこしい
 - 前回取得のバックアップとの差分だけが生成される
 - そして、生成された差分が圧縮されてS3へ保存される


### S3
デフォルトでHTTPインターフェース（閉じることも可能）
EBSに比べて費用対効果10倍以上

- ファイル削除の世代管理
フラグだけつけて実際に削除させないことも可能
バージョニング
偶発的な削除から保護する目的

- オブジェクトキー
https://doc.s3.amazonaws.com/2006-03-01/AmazonS3.html
                            →オブジェクトキー（2006-03-01はディレクトリのように見えるが、実際はファイル）

- セキュリティ
 - ACL
 - バケットポリシー
 - IAM
複数のセキュリティが適用されてる場合は、きつい方が効く

- S3 標準低頻度アクセス
- Glacier
長期間使わないリソースの場合
S3に比べて1/3のコスト
取り出し時間が3〜5時間

- ライフサイクルポリシー
削除、または低頻度アクセスやGlacierなどに移動できる


### VPC
AWSアカウント作成するとデフォルトで1つできる

- サブネット
- プライベート
- パブリック

AZ毎に作る必要がある

- ネットワーク空間は1つでも大きくても費用は変わらない
支障なければ大きめにVPCを切っておくべき

- 5個少ない数しか使えない

### ネットワーク制御機能
- FW
 - NACL 行きと返りの通信を制御しないといけないので使うケースは多くない  例えばsshを全部着る場合などに使う
 - 戻りは自動的にやってくれる
 - セキュリティグループ
  - 何個作っても費用はかからない
- ルートテーブル
- Gateway
- Direct Connect オンプレとの通信手段


### セキュリティ
- キーペア
SSH
RDP(Windowsの場合)


### IAM
- ルートアカウント
 - 5000のIAMを作成できる
- IAMユーザー 人間が払い出すので、ユーザー名、パスワード
 - コンソールなどのログイン用
- IAMグループ ユーザーをまとめる
- IAMロール リソースに付与するもの インスタンスメタデータ
 - インスタンスプロファイル
 - 3600の権限を別のAWSアカウントへ引き渡せる
   外注したり、別会社の詳しい会社に依頼するときに使用

- IAM ポリシー
権限を設定するJSON
IAMユーザー、IAMグループ、IAMロールヘ割り当てれる
複数設定できる
追加し続けると管理が大変。ある程度運用を考慮すべき


### トラフィック制御
- AutoScaling
そのものの追加料金はなし
CloudWatchで負荷を監視してスケールさせる

- 動的スケーリング
- 静的スケーリング
 - `最大台数 最小台数 基準値 を全て1にしたりして使う`

- 最大台数
- 最小台数
- 基準値


### CloudWatch
デフォルト
- CloudWatchアラーム
 - SNS/Eメール通知

- CloudWatchEvents
 - CloudWatchアラームよりさらに色々な機能を使えるもの






---
# 総括
横文字のオンパレードでスピーカーも喋りにくそう
インフラ整備や運用で時間を割くのは本当に無駄に思えてきた
既存をやろうとすると、しんどいが外部連携や外部にシステムを持つときはAWS採用を提案していきたい
AWSの中の人のセッションばっかりだったので、外の人の事例を聞きたかった
でも結構基本は色々しることができた
まだわからない部分もあるので深掘りしていきたい