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