Submit Search
Upload
AWSスポットインスタンスの真髄
•
144 likes
•
87,335 views
外道 父
Follow
Gedow style how to use aws spot instance.
Read less
Read more
Technology
Report
Share
Report
Share
1 of 59
Download now
Download to read offline
Recommended
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
そろそろSELinux を有効にしてみませんか?
そろそろSELinux を有効にしてみませんか?
Atsushi Mitsu
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal
Toru Makabe
これからはじめるインフラエンジニア
これからはじめるインフラエンジニア
外道 父
GitHub ActionsでiOSのCIを実現しよう
GitHub ActionsでiOSのCIを実現しよう
Shinya Nakajima
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
Recommended
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
そろそろSELinux を有効にしてみませんか?
そろそろSELinux を有効にしてみませんか?
Atsushi Mitsu
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal
Toru Makabe
これからはじめるインフラエンジニア
これからはじめるインフラエンジニア
外道 父
GitHub ActionsでiOSのCIを実現しよう
GitHub ActionsでiOSのCIを実現しよう
Shinya Nakajima
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
都元ダイスケ Miyamoto
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
Shinji Takao
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
NTT DATA Technology & Innovation
Amazon ElastiCacheのはじめ方
Amazon ElastiCacheのはじめ方
Amazon Web Services Japan
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
Masahito Zembutsu
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Masahito Zembutsu
例外設計における大罪
例外設計における大罪
Takuto Wada
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
Takuya Sato
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
Amazon Web Services Japan
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
外道 父
More Related Content
What's hot
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
都元ダイスケ Miyamoto
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
Shinji Takao
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
NTT DATA Technology & Innovation
Amazon ElastiCacheのはじめ方
Amazon ElastiCacheのはじめ方
Amazon Web Services Japan
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
Masahito Zembutsu
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Masahito Zembutsu
例外設計における大罪
例外設計における大罪
Takuto Wada
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
Takuya Sato
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
What's hot
(20)
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
GraalVMのJavaネイティブビルド機能でどの程度起動が速くなるのか?~サーバレス基盤上での評価~ / How fast does GraalVM's...
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
Amazon ElastiCacheのはじめ方
Amazon ElastiCacheのはじめ方
Docker道場オンライン#1 Docker基礎概念と用語の理解
Docker道場オンライン#1 Docker基礎概念と用語の理解
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
Dockerの期待と現実~Docker都市伝説はなぜ生まれるのか~
例外設計における大罪
例外設計における大罪
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Docker Compose 徹底解説
Docker Compose 徹底解説
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
Viewers also liked
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
Amazon Web Services Japan
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
外道 父
AWS Black Belt Online Seminar Amazon EC2
AWS Black Belt Online Seminar Amazon EC2
Amazon Web Services Japan
AnsibleによるHWプロビジョニング -OneViewの連携-
AnsibleによるHWプロビジョニング -OneViewの連携-
Takahiro Kida
Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)
Taro Hirose
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Shingo Kitayama
運用のためのPlaybook (Playbook for Operation)
運用のためのPlaybook (Playbook for Operation)
Shingo Kitayama
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネット株式会社
はじめての UWP アプリ開発
はじめての UWP アプリ開発
hiyohiyo
リブセンスのインフラで使ってるAnsibleのお話
リブセンスのインフラで使ってるAnsibleのお話
Shohei Koyama
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾
外道 父
Ansible はじめてみました
Ansible はじめてみました
Takeshi Kuramochi
ほんとうはこわいAnsible
ほんとうはこわいAnsible
Takahiro Nakayama
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
Shuntaro Saiba
Ansible Playbookの短時間デバッグ方法
Ansible Playbookの短時間デバッグ方法
Kishin Yagami
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
Insight Technology, Inc.
Ansibleで味わうHelion OpenStack
Ansibleで味わうHelion OpenStack
Masataka Tsukamoto
What is an Ansible?
What is an Ansible?
Shunsaku Kudo
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
hiyohiyo
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
hiyohiyo
Viewers also liked
(20)
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
AWS Black Belt Online Seminar Amazon EC2
AWS Black Belt Online Seminar Amazon EC2
AnsibleによるHWプロビジョニング -OneViewの連携-
AnsibleによるHWプロビジョニング -OneViewの連携-
Ansible 入門 #01 (初心者向け)
Ansible 入門 #01 (初心者向け)
Ansibleはじめよぉ -Infrastructure as Codeを理解-
Ansibleはじめよぉ -Infrastructure as Codeを理解-
運用のためのPlaybook (Playbook for Operation)
運用のためのPlaybook (Playbook for Operation)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
さくらインターネットにおけるServerspec導入事例(DevOps勉強会 #3 Serverspecの巻)
はじめての UWP アプリ開発
はじめての UWP アプリ開発
リブセンスのインフラで使ってるAnsibleのお話
リブセンスのインフラで使ってるAnsibleのお話
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾
Ansible はじめてみました
Ansible はじめてみました
ほんとうはこわいAnsible
ほんとうはこわいAnsible
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なインフラおじさん方にAnsibleを導入してみた
Ansible Playbookの短時間デバッグ方法
Ansible Playbookの短時間デバッグ方法
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
[B11] 基礎から知るSSD(いまさら聞けないSSDの基本) by Hironobu Asano
Ansibleで味わうHelion OpenStack
Ansibleで味わうHelion OpenStack
What is an Ansible?
What is an Ansible?
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Desktop App Converter で Microsoft ストアデビュー & 野良野良ライフ満喫!!
Similar to AWSスポットインスタンスの真髄
Automation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbix
softlayerjp
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Masaya Aoyama
クラウドのなかみ
クラウドのなかみ
Satoshi Hirata
おすすめインフラ! for スタートアップ
おすすめインフラ! for スタートアップ
Koichiro Sumi
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
Serverworks Co.,Ltd.
ニフティクラウドを使った安定運用のススメ
ニフティクラウドを使った安定運用のススメ
NIFTY Cloud
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
Daiki Kawanuma
NHNグループ合同勉強会 ライブドア片野
NHNグループ合同勉強会 ライブドア片野
livedoor
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
シスコシステムズ合同会社
ドリコムのインフラCI
ドリコムのインフラCI
Go Sueyoshi (a.k.a sue445)
サーバー初心者のためのWordPressサイト構築手順
サーバー初心者のためのWordPressサイト構築手順
IDC Frontier
Webアプリケーションは難しい
Webアプリケーションは難しい
Takafumi ONAKA
Stac2014 石川
Stac2014 石川
Tatsuya Ishikawa
A1-6 ドメイン乗っ取られた!!
A1-6 ドメイン乗っ取られた!!
JPAAWG (Japan Anti-Abuse Working Group)
JAWS-UG クラウド専業SIer(CIer)になってみた結果
JAWS-UG クラウド専業SIer(CIer)になってみた結果
Serverworks Co.,Ltd.
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
whywaita
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Toru Yamaguchi
AWSオンリーで実現するIoTクラウド基盤
AWSオンリーで実現するIoTクラウド基盤
Godai Nakamura
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Yasuaki Matsuda
ゆるかわPhp
ゆるかわPhp
Ryota Mochizuki
Similar to AWSスポットインスタンスの真髄
(20)
Automation with SoftLayer and Zabbix
Automation with SoftLayer and Zabbix
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
クラウドのなかみ
クラウドのなかみ
おすすめインフラ! for スタートアップ
おすすめインフラ! for スタートアップ
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
2012年03月 経済産業省セミナー「クラウドは敵か?味方か?」
ニフティクラウドを使った安定運用のススメ
ニフティクラウドを使った安定運用のススメ
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
エンプラに Kubernetes を 導入してみて分かった 4つの Lessons Learned
NHNグループ合同勉強会 ライブドア片野
NHNグループ合同勉強会 ライブドア片野
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
Cisco Modeling Labs (CML)を使ってネットワークを学ぼう!(応用編)
ドリコムのインフラCI
ドリコムのインフラCI
サーバー初心者のためのWordPressサイト構築手順
サーバー初心者のためのWordPressサイト構築手順
Webアプリケーションは難しい
Webアプリケーションは難しい
Stac2014 石川
Stac2014 石川
A1-6 ドメイン乗っ取られた!!
A1-6 ドメイン乗っ取られた!!
JAWS-UG クラウド専業SIer(CIer)になってみた結果
JAWS-UG クラウド専業SIer(CIer)になってみた結果
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
作って(壊して?)学ぶインターネットのしくみ サイバーエージェントの実験用ASの紹介 / Introduce experimental AS in ...
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
AWSオンリーで実現するIoTクラウド基盤
AWSオンリーで実現するIoTクラウド基盤
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
Microsoft Azureで描く未来 !CLR/H &Windows女子部 ー lesson1
ゆるかわPhp
ゆるかわPhp
Recently uploaded
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Atomu Hidaka
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
sugiuralab
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
Shota Ito
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
osamut
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
sugiuralab
Recently uploaded
(7)
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
AWSスポットインスタンスの真髄
1.
Copyright gedow.net All
Rights Reserved. 財布の紐を限界まで締める! AWSスポットインスタンスの真髄 外道父@GedowFather 2015/06/17 #2 市ヶ谷Geek★Night
2.
Copyright gedow.net All
Rights Reserved. 2 自己紹介 ■私は 外道父@GedowFather ■所属 ドリコム ■職種 インフラエンジニア ■ブログ 外道父の匠
3.
Copyright gedow.net All
Rights Reserved. 3 ま だ オ ン デ マ ン ド で お 布 施 し て る の ? そ ら ウ ハ ウ ハ で 売 上 高 を 公 開 し ち ゃ い ま す わ
4.
Copyright gedow.net All
Rights Reserved. 4 目次 1. 基本と目的 2. 深イイ話 3. アーキテクチャ 4. その他の工夫
5.
Copyright gedow.net All
Rights Reserved. 基本と目的
6.
Copyright gedow.net All
Rights Reserved. 6 スポットインスタンスを三行で 1. 費用が超安い! 2. 起動が少し遅い! 3. 強制削除されるリスク!
7.
Copyright gedow.net All
Rights Reserved. 7 安い理由は入札式 余っているリソースを使ってもらうため 需要と供給により価格が変動する 入札価格が変動価格を上回れば起動を継続 でき、下回れば強制削除される 入札価格 変動価格 起動できない 起動できる 強制削除 起動できる $0.1 $0.2 $0.01 $0.05 $1.0
8.
Copyright gedow.net All
Rights Reserved. 8 費用の比較 オンデマンド 100% リザーブドインスタンス 55~75% スポットインスタンス 最小 14% 最大 1000% リザーブドは事業規模の変化度合いに合わ ないし、1年経てばc3=>c4のような上位 互換が期待できるのでメインにはしない スポットのワクワク感
9.
Copyright gedow.net All
Rights Reserved. 9 価格変動の度合い 予測は不可能 xlarge以下は比較的 落ち着いている それ以上は無慈悲な急騰が常 c3.4xlarge の平和な24時間 $0.15 ~ $0.25 c3.4xlarge のよくある一週間 最大 $5.0
10.
Copyright gedow.net All
Rights Reserved. 10 高スペックの価格変動 c3.8xlarge は1ヶ月間に数十回も高騰 オンデマンドの 2~5倍 おまえらは誰と闘っているんだ状態 このオンデマンドは $1.68
11.
Copyright gedow.net All
Rights Reserved. 11 起動時間が少し遅い オンデマンドはポチッてから 約3~4分 で起動が完了する スポットはまず入札処理が入り、入札が 成功してから起動に入るため 約7~8分 を必要とする
12.
Copyright gedow.net All
Rights Reserved. 12 強制削除 入札価格 ≧ 変動価格 = セーフ 入札価格 < 変動価格 = アウト 一度でもアウトの条件を満たすと、 1~2分で強制的にTerminateされる 1分経過 スポット 入札価格 AWS神
13.
Copyright gedow.net All
Rights Reserved. 13 基礎知識から導き出される結論 リスクを排除して スポットだけで 運用したら激安じゃない
14.
Copyright gedow.net All
Rights Reserved. 深イイ話
15.
Copyright gedow.net All
Rights Reserved. 15 リソースは全く同じ オンデマンドのインスタンスも、スポッ トインスタンスも、元となるサーバーの リソースは全く同じ スポットだからCPUやストレージの品質 が劣っているということは一切ない オンデマンド オンデマンド スポット ホストサーバー
16.
Copyright gedow.net All
Rights Reserved. 価格ルール
17.
Copyright gedow.net All
Rights Reserved. 17 変動/入札価格の最大値 変動価格はオンデマンド価格の10倍 まで跳ね上がる 入札価格も10倍までとなる オンデマンドが $0.294 なので 最大で $2.94 まで跳ね上がる
18.
Copyright gedow.net All
Rights Reserved. 18 2015年4月中旬までの価格ルール 最大入札価格はオンデマンドの4倍まで それ以上は申請して上限を引き上げる形式 価格の継続的な異常高騰を和らげるために 改定された 企業(A) 企業(B) スポットの存在意義にそぐわない利用状況にメスが入った 変更が入った瞬間、 オンデマ10倍以上の LaunchConfiguration では起動できなくなる というトラブルが発生 (外道式青天井界王拳20倍施策より)
19.
Copyright gedow.net All
Rights Reserved. 19 強制Terminateを避けるテクニック 最大変動価格 = 最大入札価格 = オンデマの10倍 すなわち オンデマンドの 10倍で入札したら 落とされない!! 基本的にTerminate
20.
Copyright gedow.net All
Rights Reserved. 安全な停止
21.
Copyright gedow.net All
Rights Reserved. 21 入札価格超過以外の落とし穴 需要と供給の関係で成り立っているので、 需要が急増した場合は入札や変動価格の高 低に関わらず強制Terminateが走る可能性 がある 変動価格MAXでよく起こる 発動時に削除されるかは運
22.
Copyright gedow.net All
Rights Reserved. 22 強制Terminateをインスタンス自身が知る ローカルのメタデータで、神様による無慈悲 なTerminate発動予定時間を取得できる http://169.254.169.254/latest/meta-data/spot/termination-time 普段は 404 Not Found を返す 価格超過やリソース不足によるTerminate確定か ら数秒後に200 OKと停止時刻を返すようになる 5秒間隔でのチェックを推奨されている 検知したら、新規リクエストの受け付けを停止す るなど、必要な処理を済ませる AWS
23.
Copyright gedow.net All
Rights Reserved. 23 通常のインスタンス破棄前に任意の処理を行う AutoScaleにおける起動完了前や削除実行 前に、任意秒を待機し、任意の処理を行う ための LifecycleHook という機能がある 削除前に待機することで、安心安全に落と すための処理を入れることができる ココで止まってもらい ココで必要な処理を行い 自身でシステムに通知するか、 任意秒が過ぎたら、 次のプロセス(削除処理)へ移る
24.
Copyright gedow.net All
Rights Reserved. 制限値
25.
Copyright gedow.net All
Rights Reserved. 25 入札数の制限 アカウントごとの設定に、EC2インスタン ス数の上限数が 20 といった制限値がある 入札数にも制限があり、デフォルトで 20 となっている 各種設定と同様、申請で引き上げ可能 入札数のカウントはインスタンスを削除し たらすぐ減るわけではないので、短時間で 起動と削除を繰り返すと入札できなくなる
26.
Copyright gedow.net All
Rights Reserved. アーキテクチャ
27.
Copyright gedow.net All
Rights Reserved. 27 メインをスポットにする覚悟を決める 入札価格をオンデマンドの10倍にす ることで強制Terminateを避ける スポットの仕様変更や機能追加に追随 し続ける 『 コ ス ト を 抑 え る 』 『 安 全 に 運 用 し 続 け る 』 「 イ ン フ ラ エ ン ジ ニ ア 」の
28.
Copyright gedow.net All
Rights Reserved. 28 制限値を上げる申請をする デフォルト値 申請値(例) EC2インスタンス数 20 400 入札数 20 400 AutoScalingGroup数 20 100 AutoScalingGroupは構築時に気づけるが、イ ンスタンス関連は運用に入ってから引っかかる可 能性があるので注意する 申請は1営業日もあれば通るので焦らなくてOK 多すぎず少なすぎず、気持ち多目に
29.
Copyright gedow.net All
Rights Reserved. AutoScalingGroup
30.
Copyright gedow.net All
Rights Reserved. 30 AutoScalingGroupを作成する Availability Zone [1a] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台
31.
Copyright gedow.net All
Rights Reserved. 31 AutoScalingGroupを細かく分ける理由 Availability Zone [1a] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 1~100台 Spot c4 1~100台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台 変動価格がインスタンスタイプ/AZ単位のため 複数のインスタンスタイプを併用し、高騰による 強制Terminateのリスクを減らすため 監視用グラフを永存したり、アプリログのサンプ リングを送信するため 10 グループ!
32.
Copyright gedow.net All
Rights Reserved. 32 オンデマンドも併用する理由 スポットが不調な時に予備のスケールアウト となる 急激なスケールアウトが必要になった時、ス ポットより素早く起動できる 監視用インスタンスはホスト名やIPアドレス を固定で据え置きたい
33.
Copyright gedow.net All
Rights Reserved. 33 スポットメインのスケール条件 スポット オンデマンド 監視用 min 1 1 1 max 100 100 1 CPU条件 増減率 CPU条件 増減率 increase(1) 40% 20%↑ 70% 20%↑ なしincrease(2) 80% 80%↑ 90% 80%↑ decrease 20% 20%↓ 40% 20%↓ 平時はスポットだけが増設され、有事はオンデマンドも増設 落ち着けばオンデマンドから削減される (スポット1~100✕4グループ)+(オンデマンド1✕6 グ ループ) が平時の台数となる
34.
Copyright gedow.net All
Rights Reserved. 34 高騰したスポットは破棄する type AZ min max desired スポット c3 1a 1 100 25 1c 1 100 28 c4 1a 1 100 22 1c 1 100 25 オンデマ c3 1a 1 100 1 1c 1 100 1 c4 1a 1 100 1 1c 1 100 1 監視用 c3 1a 1 1 1 c4 1c 1 1 1 min max desired 1 100 25 0 0 0 1 100 22 1 100 25 1 100 1 1 100 1 1 100 1 1 100 1 1 1 1 1 1 1 高騰 グループ単位で価格を監視し、高騰と判断したらインスタン スを破棄してグループの稼働を停止する 残る3グループの負荷は上がるが平常運転の範囲内 価格が落ち着いたら、またスケールアウトを開始する
35.
Copyright gedow.net All
Rights Reserved. 35 高騰と平常の判断条件 直近1時間平均を比較値とする 1時間に数十ある履歴の、価 格と割当時間から計算する わずか数分の突発高騰でのイ ンスタンス破棄を防ぐため 16時に比較する値は $3.0 ではなく $0.5 程度になる 1時間平均の変動価格 = 比較値 高騰 if 比較値 ≧ オンデマンド価格✕1.2 平常 if 比較値 < オンデマンド価格✕0.8 ※条件を離すことで自動処理の連続発動を回避
36.
Copyright gedow.net All
Rights Reserved. 36 高騰リスクの低減 c3だけだと1a&1cが同時に高騰する可能性が高く、最悪 リソースがゼロになるため、c4を併用することで最悪でも リソース半減に抑えられる さらに m3/m4/r3 を併用という選択もありうる Spot c3 100% Spot c4 100% 1a Spot c3 100% Spot c4 100% 1c Spot c3 133% Spot c4 1a Spot c3 133% Spot c4 133% 1c 価格高騰により 1グループ死亡しても 残るグループの負荷は 4/3倍になるだけ
37.
Copyright gedow.net All
Rights Reserved. 通常停止対策
38.
Copyright gedow.net All
Rights Reserved. 38 LifecycleHookで安全にシャットダウン ココで3600秒止まってもらい インスタンス自身がLifecycleHookに 入ったと認識したら必要な処理を行い Complete通知を送って終了する。 完了までの時間はサービスの性質次第 スケールインや高騰時のグループインスタンス破棄において、 安全かつ必要な処理を済ませる ELBから外す、ユーザー切断を待つ、タグを付ける、監視 サーバーから自ホストのデータを削除する 処理が完了したらAWSに通知を送ってTerminate
39.
Copyright gedow.net All
Rights Reserved. 39 LifecycleHookの通知と問題点 LifecycleHookの通知はインスタンスが直接受けるのではな く、SNS/SQSを通して受け取る メッセージ内にCompleteを送るためのトークンがある SNSだと余剰サーバーが必要になるので却下 SQSだとインスタンス自身で取りにいけるが、キューは任 意のメッセージを受け取ることができない SNS 管理 サーバー 削除対象 サーバー SNSの場合 PUSH? PULL? SQS 削除対象 サーバー SQSの場合 こんなことで複雑な仕組みにしたくない キューから自身宛のメッセージを取得しづらい 何度も取得処理をして時間がかかる可能性がある
40.
Copyright gedow.net All
Rights Reserved. 40 LifecycleHookの通知を取得する仕組み 10秒毎に全インスタンスでキューをチェック あれば必ず1通は取得できるので、インスタンスIDとトーク ンを抜き出し、該当のインスタンスにタグを登録 さらにインスタンス自身のタグをチェックし、該当タグがあ れば削除前処理を行い、Complete通知をして完了する SQS 削除対象 サーバー (B) サーバー (C) サーバー (A) Send Message Get & Delete Message Create Tags LifecycleTransition LifecycleActionToken
41.
Copyright gedow.net All
Rights Reserved. 41 Linuxのinitシステム管理では挙動が不確か 正常なシャットダウン処理の場合、initスクリプト に sleep を仕込むことでTerminateを遅らせるこ とができそうだが無理 Terminateによるshutdown実行後は、sleepで耐 えていても数分後にインスタンスを強制削除される LifecycleHookが確実な手段だし、便利なのでオス スメ だがトークンの受け取りが厳しい。メタデータに埋 め込んでくれ
42.
Copyright gedow.net All
Rights Reserved. 強制停止対策
43.
Copyright gedow.net All
Rights Reserved. 43 強制Terminateに備える http://169.254.169.254/latest/meta-data/spot/termination-time 入札価格超過によるTerminateはないが、需要/供 給のリソース不足で落とされるので仕込む Bashデーモン 5秒間隔で監視し、検知したらLifecycleHookと 同じ削除前処理を実行する
44.
Copyright gedow.net All
Rights Reserved. 44 唯一の弱点 1回1回の処理時間が短いHTTPは問題ない 1つの処理に数分数十分以上の持続接続が必要な場 合は、クライアントやジョブの処理終了に間に合わ ず落とされてしまう WebSocket / MQTT や 集計処理 など 切断時にクライアント再接続やジョブ再実行する仕組み Terminateを検知した時点でそれを促す仕組み Terminate検知 Terminate実行1~2分間 HTTP 長時間の持続接続サービス この間に処理を安全に終えられるか が分かれ目となる 過ぎるとユーザーに 不利益が生じるため 工夫が必要になる クライアントが強制切断される
45.
Copyright gedow.net All
Rights Reserved. 費用効果
46.
Copyright gedow.net All
Rights Reserved. 46 オンデマンドのみと併用の比較 オンデマンドのコストを 100 とする 好調スポットのコストを 15 とする 最小台数と大規模台数でそれぞれ、同台 数におけるオンデマンドのみのコストと、 スポット構成のコストを比較する
47.
Copyright gedow.net All
Rights Reserved. 47 最小台数の場合 Availability Zone [1a] Spot c3 1台 Spot c4 1台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 1台 Spot c4 1台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台 Spotコスト = 1台✕4グループ✕15 = 60 Ondemandコスト = 1台✕6グループ✕100 = 600 Spot + Ondemand = 660 Ondemandのみ = 1000>34%削減
48.
Copyright gedow.net All
Rights Reserved. 48 大規模台数の場合 Availability Zone [1a] Spot c3 30台 Spot c4 30台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c3 1台 Availability Zone [1c] Spot c3 30台 Spot c4 30台 Ondemand c3 1台 Ondemand c4 1台 監視用 Ondemand c4 1台 Spotコスト = 30台✕4グループ✕15 = 1800 Ondemandコスト = 1台✕6グループ✕100 = 600 Spot + Ondemand = 2400 Ondemandのみ = 12600>81%削減
49.
Copyright gedow.net All
Rights Reserved. 49 1時間平均の価格変動グラフ(1ヶ月間) Ondemand価格 Ondemand価格 c3.xlarge c4.xlarge ほぼオンデマンドの 20~25%をキープ 一時荒れるも避難し、 大半を最低価格の 14%でキープ
50.
Copyright gedow.net All
Rights Reserved. 50 インスタンスタイプの選択 希望は 2xlarge あたりだった 最初に採用したのは c3/c4.xlarge c4がご乱心 & m3が安定したので c3/m3.xlarge に避難 m2 は安定しているがHVM非対応 新しい m4 は多分、数カ月後に荒波 CC2/CR1 もわりとブルーオーシャン 高スペック+Dockerという手も……
51.
Copyright gedow.net All
Rights Reserved. 51 オンデマンドいる? いざ運用してみると、思いの外スポットのス ケールアウトだけで稼働できてしまう オンデマンドがいらない気になるけど、そこ までスポットは信用するべきものでもない 最終防衛ライン 1セットにつき6つのオンデマンドが確定な ので、リザーブドインスタンスを適用すると さらに削減できる
52.
Copyright gedow.net All
Rights Reserved. その他の工夫
53.
Copyright gedow.net All
Rights Reserved. 53 AutoScalingGroup管理の簡略化 LaunchConfigurationが多い production / staging spot / ondemand c3 / c4 AutoScalingGroupが多い 同上 1a / 1c 監視用 CloudWatchが多い Increase (peace / pinch) Decrease 監視用は除く >合計8件 >合計20件 >合計48件 自動化した 作成・削除・更新など全て
54.
Copyright gedow.net All
Rights Reserved. 54 独自TimeBasedスケールアウト 12時 23時 サービスの性質上、12時と23時がピークタイムであり、 12~23時の間はイベントやメンテナンスによる急激な 増減がある。特にメンテ明けの台数は危険 11:30 にMinSizeを、その時点のInService✕N倍の台 数に強制増設する(1.5~3倍) 23:30 にMinSizeを元に戻す 日中の台数節約放棄の代わりに運用し易さと安定を得る 強制Increase 自然な増減に 切り替え 最低台数を キープ
55.
Copyright gedow.net All
Rights Reserved. 55 AZ間のレイテンシ差に対応する(1) AZ [1a] EC2 AZ [1c] EC2 RDS 速い 少し遅い RDSやElastiCacheが同じAZにあるとレイ テンシが低い 違うAZからだと遅くはないが、同AZより はレイテンシが高い AZ [1a] Spot c3 10台 Spot c4 9台 AZ [1c] Spot c3 3台 Spot c4 2台 レイテンシが低いほど多くCPU 処理をできるためスケールアウ トされやすい CPU性能が低いほどスケールア ウトされやすい AZとインスタンスタイプで台 数に偏りが出ると、リスクも偏 ることになる
56.
Copyright gedow.net All
Rights Reserved. 56 AZ間のレイテンシ差に対応する(2) AZ [1a] Spot c3 6台 Spot c4 6台 AZ [1c] Spot c3 3台 Spot c4 2台 Max 6 Max 6 Max 100 Max 100 グループごとの台数を監視 最低台数より+4台以上の グループはMax値を抑える Max = Desired 差が狭まったらMaxを戻す この仕掛による挙動とリスク 抑えつけたグループの分、スケールアウトの全体増加率が 減少するため、1グループあたりの増加率で調整する Increase条件がCPU 40%だとすると、抑えつけたグルー プはCPU60%前後にまで上がる AZを分けなくても、実はそもそもこうなっているはず リソースを多目に消費することは台数節約でもある
57.
Copyright gedow.net All
Rights Reserved. 57 スクリプトで AWS CLI を使わない AWS CLIは重い(CPUをメチャ喰う) 手動や数時間に1回の実行ならば問題ない 数十秒単位だとCPU利用率のグラフが常に10%前 後など無駄すぎる消費 重いのは認証処理 シェルのコマンドベースだと毎回この処理が入る 軽量プログラミング言語+SDKで書けば、認証 を確保したままループ処理をできるため軽い 最初はBashで書いたがRubyに書きなおした 手動実行 管理スクリプト 自動実行 ジョブスクリプト 監視アラート/グラフ用 値出力スクリプト
58.
Copyright gedow.net All
Rights Reserved. 58 AWS Japan と同じ社屋に入る アルコタワー アネックス Amazon Japan アルコタワー 19F AWS Japan 17F ドリコム 他の階も Amazonが 徐々に侵食中 相談や新着情報を伝えに天上界から降りてきてくれ、終 わると天上界にお帰りになられる 天上界にお伺いし、USチームと電話会議したり、来日し ているとディープな情報交換できる(完璧な通訳付き)
59.
Copyright gedow.net All
Rights Reserved. 59 俺 の コ ス ト が 高 騰 し ち ま う か ら な ! で も …… で も で も ス ポ ッ ト は 怖 い し や め た ほ う が い い と 思 う よ ! fin
Download now