You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
ここで指定する「アベイラビリティーゾーン」は、「リージョン内でさらに独立して分離されたデータセンター群の事」と捉えて頂ければOKです。 各アベイラビリティーゾーンは物理的に一定距離離れており、落雷、地震などの電源やその他のインフラストラクチャを共有していないため、複数のアベイラビリティーゾーンを使う構成(MultiAZ)を取ると、万が一1個のアベイラビリティーゾーンが落ちても高い可用性を得ることが出来ます。 また、VPCは複数のアベイラビリティーゾーンに跨がってリージョン単位で作成出来るのに対して、サブネットはアベイラビリティーゾーン単位で作成する必要があります。 そんなわけで、サブネットを4つ作成しました。 現在の構成はこんな感じで、VPC内にサブネットが4つ作成された構成になります。 インターネットゲートウェイを作る インターネットゲートウェイは、VPCとインターネットとのゲートウェイ
基本に立ち返ろうということで、AWSのAutoScalingの仕様の確認です。前回は、スケーリングポリシーを中心に確認でした。今回は、起動や終了に関わる仕様ということで、猶予期間・ウォームアップ・クールダウン・終了ポリシーなどの解説になります。 前回 AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい ヘルスチェックと猶予期間 まず最初にヘルスチェックと猶予期間です。ヘルスチェックは、AutoScalingの管理対象下のインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられます。 Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto
AWS認定試験の対策本を書いていることもあって、試験についての相談を受けることがよくあります。その中で、AutoScaling関係の問題が難しいという相談が多い。話しを聞いていると、ELBの機能かAutoScalingの機能か切り分けて理解していないケースが多いようです。実務的には、ELBとAutoScalingは一体で使うことが多く、無理もないかなぁと思います。 私も曖昧な理解している所が多かったので、改めてAutoScalingの機能について整理してみました。そうすると思っていた以上に多くの機能がアップデートされていて、定期的に知識のアップデートすることが必用だなと痛感させられます。ということで、今日はAWSのAutoScalingについて整理してみます。 EC2 AutoScaling EC2 AutoScalingは、EC2インスタンスの利用状況に応じて動的に増減させるサービスです
こんにちは、yagiです。 本日は、CodeDeployを利用してAutoScalingグループにサンプルアプリケーションをデプロイして確認しましたのでご紹介します。途中エラーとなり対応した点もあったので、その点も記載します。 AWS CodeDeployとは? AWS CodeDeploy は、Amazon EC2 インスタンス、およびオンプレミスで稼働するインスタンスを含む、さまざまなインスタンスへのコードのデプロイを自動化するサービスです。AWS CodeDeploy を使用すると、アプリケーションの複雑なアップデート処理、デプロイ中のダウンタイムの回避、新規機能の迅速なリリースが容易になります。AWS CodeDeploy を使用すると、エラーを起こしやすい手動操作やインフラストラクチャのサービススケールの必要性を排除しながら、デプロイの自動化を行うことが可能となり、1 つのインス
Amazon EKS Advent Calendar 2019の3日目です 最近EKSにおけるAutoScalingについて仕事でいろいろ試して、知見がだいぶたまったのでそれをまとめてみようと思います。 (といっても商用環境でこれを適用したというわけでなく、検証した程度なので商用環境で耐えれる内容ではないかもしれません..) k8sのAutoScalingについて最初にk8sにおけるAutoScalingについて触れておこうと思います。 k8sの世界でスケールさせる必要があるリソースはなんでしょうか? PodとNodeですね。 Podはk8sの世界に置いてデプロイできるアトミックなリソースですし PodはNodeの上に配置されるため、Pod数が増加してきたときに配置に耐えれるようにスケールできる必要があります。 これらのスケール方法ですが Podであれば、単純に新しいPodを配置したりDe
EC2 AutoScalingでインスタンスタイプの重み付けができるようになりました。 どういうこと? Auto Scaling Groupの設定では、一つのGroup内に複数のインスタンスタイプを指定することができます。 各インスタンスタイプごとに重み付けをすることが可能になりました。 AutoScaling Groupは、稼働中のインスタンスの重みの合計が希望キャパシティと同等かそれ以上になるようにフリートを維持します。 まずは重み付けとはどういうことか、理解する 簡単な例を使って重み付けの概要を理解しましょう。以下はAuto Scaling Groupの設定画面です。 赤枠で囲ったところに重みを入力できるようになっています。が、一旦入力なしでいきます。 インスタンスタイプも t2.small一種類だけです。 オレンジ枠で囲った通り、希望キャパシティは4です。作成されるインスタンス群は
中山(順)です 少し前にElasticache for RedisでAutoScalingが利用できるようになりました。 Amazon ElastiCache for Redis now supports auto scaling 早速試してみましょう。 要件 まずは動作要件を確認します。 Prerequisites Redis (cluster mode enabled) clusters running Redis engine version 6.x onwards Instance type families - R5, R6g, M5, M6g Instance sizes - Large, XLarge, 2XLarge Auto Scaling in ElastiCache for Redis is not supported for clusters running in
At some point, your needs for improving database performance may run into a threshold where optimization and tuning are no longer enough. If you cannot change the database engine and can no longer tune the parameters for your workload, you need to use scaling. As it is widely known, scaling may be either vertical or horizontal. Vertical scaling means adding more resources to a single node. Usually
こんにちは!コンサル部のinomaso(@inomasosan)です。 re:Invent 2021にて発表された、AWS Compute OptimizerでEC2とAutoScalingに拡張インフラストラクチャメトリクスが追加されたので、紹介していきます。 概要 AWS Compute Optimizerはデフォルトで過去14日間のCloudWatchメトリクスを分析し、コスト削減やパフォーマンス向上について推奨事項を提供することができます。 今回のアップデートで追加された拡張インフラストラクチャメトリクスを有効化することにより、AWS Compute OptimizerはEC2とAutoScalingのCloudWatchメトリクス履歴を最大3ヶ月保存して分析できるようになりました。 拡張インフラストラクチャメトリクスは、以下のレベルで有効化できます。 リソースレベル AWSアカウ
みんな大好き Autoscaling の時間です☆ 少し長めになっちゃったのですが、分割するとわかりづらくなりそうだったので1つでぶっ込んでいきます。 さてここで新たに、helm という仕組みが登場します。Kuberntes におけるパッケージ管理みたいなもので、これも Terraform でやっつけちゃうので安心して・・・うーん、最後までいければいいですね!くらいな感じです。 EKS における Autoscaling の仕組み まずおさらいとして、ALB + EC2 の時はどうやっていたかというと、Autoscaling Group に CloudWatchAlarm を組み合わせて、例えばCPU使用率を条件に、何%を超えたら既存台数の何%を増加、何%より低くなったら既存台数の何%を減少、のように実現していました。 これがガラリと変わって CloudWatchAlarm とオサラバします
At Mercari, the responsibilities of the Platform team and the service development teams are clearly distinguished. Not all service owners possess expert knowledge of Kubernetes. Also, Mercari has embraced a microservices architecture, currently managing over 1000 Deployments, each with its dedicated development team. To effectively drive FinOps across such a sprawling landscape, it's clear that th
はじめに ECS+Fargateでサーバレス&運用省エネにシステムを構築しているのだから、やはりここは負荷量に応じた運用負荷も軽減したい。 TerraformでサクッとAutoScaling設定をしてみよう。 なお、本記事ではキャパシティプロバイダは使用しないケースで対応している。 また、マルチAZ構成を前提としてTerraformを書いている。Fargateの前段に配置するELBは、クロスゾーン負荷分散を有効にしておかないと、AutoScalingで1台増設が走ったときに正しく分散されないので注意(クロスゾーン負荷分散はNLBのみデフォルトでOFF)。 ECS+FargateのTerraform設定 今回はこの部分は本筋ではないので割愛する。 自分の過去記事では、↓このあたりが参考になると思う。 Terraformの初心者がAmazon EC2に実行環境を作ってECS Fargateなア
Facebook’s web tier is one of the main services that handle HTTP requests from people using our services each time they interact with Facebook. It is a massive global service distributed across multiple data centers throughout the world. Since we have people from all over the world using our services, the load on the web tier varies throughout the day, depending on the number of people using our s
AWS Database Blog Amazon DocumentDB (with MongoDB compatibility) read autoscaling Amazon Document DB (with MongoDB compatibility) is a fast, scalable, highly available, and fully managed document database service that supports MongoDB workloads. Its architecture supports up to 15 read replicas, so applications that connect as a replica set can use driver read preference settings to direct reads to
Circle CI + rails + AWS で自動テスト、自動デプロイが失敗した(Autoscaling 使用)RailsAWSCircleCICodeDeploy 概要 うまくいかなかったので、teratailの下記の質問に答えていただけたらとても嬉しいです。 https://teratail.com/questions/359594 前回書いた下記の記事からの続きです。 EC2 + RDS + Capistrano + unicorn + nginxでrailsアプリを自動デプロイ メモ 前回はCapistranoでしたが今回はCode〇〇 の4つを使った自動デプロイを行います。 まずは自動テストをCircleCIで、できるようにします。 database.yml の編集 テスト用のデータベースが使えるよう、前回からdatabase.ymlを変更 もしかしたら必要ない記述もあるかも
Serverless FrameworkでLambda Provisioned ConcurrencyのAutoScalingを実装する 今回はLambdaのProvisioned Concurrencyを指定された時間帯のみスケールアウトする環境をServerless Frameworkを使って実装する方法についてご相談いただきましたので、クラスメソッドらしくブログで回答したいと思います。 Provisioned Concurrency(おさらい) Provisioned ConcurrencyはLambda関数の実行環境を予め待機させておくことで、コールドスタートによるスタートアップ時間を短縮し、処理時間の短縮や応答性の向上を実現する機能です。 実行時間あたりの料金は通常の料金よりも安く設定されていますが、一方で待機時間でも料金が発生する仕組みとなっています。 背景(前提) 特定の時間
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く