AWS Summit 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の中の人のセッションばっかりだったので、外の人の事例を聞きたかった
でも結構基本は色々しることができた
まだわからない部分もあるので深掘りしていきたい