並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 36 件 / 36件

新着順 人気順

fargateの検索結果1 - 36 件 / 36件

  • Web アプリケーションにおける Amazon ECS / AWS Fargate アーキテクチャデザインパターン - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

    こんにちは。AWS Container Hero の新井です。 Amazon ECS の登場から間もなく 10 年が経ちますが、その間、ECS ⾃体の進化に加えて、さまざまな AWS マネージドサービスとの連携が可能になりました。 現在では、コンテナベースのワークロードを活⽤することで実現できないことを探す⽅が難しいほど、柔軟なアーキテクチャが構築できるようになっています。 しかし、⾃由度が⾼い分、要件に合ったアーキテクチャを模索する際には、迷うことも多いでしょう。 AWS上でシステムを適切に構築するためには、あらかじめサービス間のつなぎ⽅やパターン、その特徴を把握しておくことが重要です。 これにより、フィージビリティを迅速に確認でき、その後のトライアンドエラーのサイクルを加速させることができます。 今回は、最新の AWS サービスアップデートを踏まえつつ、Amazon ECS / AWS

      Web アプリケーションにおける Amazon ECS / AWS Fargate アーキテクチャデザインパターン - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
    • 監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ

      こんにちは、新規プロダクトの開発をしています、a2 (@A2hiro_tim )です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開

        監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ
      • 3 台の Raspberry Pi で始める自宅 Kubernetes クラスタの構築 - Qiita

        はじめに 最近 Raspberry Pi を3台購入し、自宅に Kubernetes クラスタを構築しました。 この記事ではその体験記を共有します。 また、自宅 k8s を構築する際に参考になる記事になる事も目指しています。 モチベーション 仕事で GCP 上で Kubernetes を使ったので、個人で Kubernetes クラスタを構築してさらに学習を深めたいと思いました。 実務ではクラウドサービスを使いますが、維持費が高額です。一日システムを立ち上げておくだけで数千円、一ヶ月では数万円かかってしまいます。 minikube などを用いてローカル環境で Kubernetes を動かすこともできますが、シミュレーター上の動作になってしまうので、どうせなら実際の環境に近いものを構築したいと思いました。 そこで、Raspberry Pi を用いることで、実際の環境に近い学習環境を構築してみ

          3 台の Raspberry Pi で始める自宅 Kubernetes クラスタの構築 - Qiita
        • 円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ

          こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ(キャッシュ不足に陥るまでの残存期間)を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、

            円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ
          • AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう | Amazon Web Services

            Amazon Web Services ブログ AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう 通常、組織はAWS サービスを活用してワークロードのオブザーバビリティと運用の優秀性を高めています。しかし、多くの場合、オブザーバビリティメトリクスが提供されたときのチームが取るべき対応は不明確であり、どのメトリクスに対処が必要で、どのメトリクスがノイズにすぎないかを理解することは難しい場合があります。たとえば、アラームがトリガーされるまで 10 分以上かかる場合、根本的な問題を軽減するためにチームが取れる対処が遅れてしまいます。この問題への理想的な解決策は、ネットワークの障害を防ぐために、オブザーバビリティメトリクスからアラームの起動までの時間を短縮することです。実装やアーキテクチャの制限により、メトリクスデータは常に CloudWatch

              AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう | Amazon Web Services
            • メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ~NTTデータに学ぶ、オブザーバビリティの取り組み~ - Findy Tools

              公開日 2024/08/14更新日 2024/08/09メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ~NTTデータに学ぶ、オブザーバビリティの取り組み~ オブザーバビリティの重要性が高まっている現在、その実現に向けたオープンソースプロジェクトであるOpenTelemetryが注目を集めています。一方、OpenTelemetryの具体的な導入事例やOpenTelemetryを用いたオブザーバビリティの取り組みについては、発信されている情報はまだ多くありません。 そんななか、Findy Toolsでは株式会社NTTデータの取り組みに注目。NTTデータでは、クラウドネイティブ環境やマイクロサービスアーキテクチャの採用増加に伴い、システムが複雑に。この課題に対応するため、OpenTelemetry を軸としたオブザーバビリティの実現に積極的に取り組んでいるといいます。 今回

                メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ~NTTデータに学ぶ、オブザーバビリティの取り組み~ - Findy Tools
              • はてなブログや GigaViewer で使われている画像変換プロキシを EC2 から EKS に移行しました - Hatena Developer Blog

                こんにちは、サービスプラットフォームチーム アルバイトの id:walnuts1018 です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の 8 月号です。7 月の記事は id:masayoshi さんの はてなで最近実施している SRE 研修の紹介 でした。 今回は、社内共用の画像変換プロキシである、「Scissors」というサービスを EC2 から EKS に移行したお話をしたいと思います。 画像変換プロキシについて 課題点 サービスプラットフォームチームにおける EKS やりたいこと 移行に関する懸念点 Scissors 専用の Node を用意する Pod / Node のオートスケール オートスケールの検証 負荷試験 1 回目 負荷試験 2 回目 リリース まとめ/ふりかえり 画像変換プロキシについて はてなでは「Scissors」という内製の画像変換プロ

                  はてなブログや GigaViewer で使われている画像変換プロキシを EC2 から EKS に移行しました - Hatena Developer Blog
                • Amazon ECSのデプロイにecspressoを使うとビルド・デプロイの境界やアプリ・インフラのIaC境界が明確になる ~ fujiwara-ware OSS ~ | DevelopersIO

                  クラスメソッドは2024年に5つのOSSに対して支援を実施しました 当方が推薦した @fujiwara さん作による Amazon ECSのデプロイツールである ecspressoが選定されたので、簡単に紹介します。 継続的デリバリーの責任範囲を明確にするecspresso ecspresso(「エスプレッソ」と発音します)はAWSのコンテナサービスAmazon ECSのデプロイツールです。 ECSでのデリバリーを思い出してみましょう。 ECSのデリバリーは、新しいコンテナイメージのビルドと、新しいコンテナイメージのデプロイの2つのフェーズに分かれている ECSのデプロイは、タスク定義を更新し、サービスの参照するタスク定義を更新すること 頻繁に更新されるアプリケーションに対して、VPCやALBといったインフラストラクチャの更新頻度は低く、この2つの更新のライフサイクルは大きく異なる 以上を

                    Amazon ECSのデプロイにecspressoを使うとビルド・デプロイの境界やアプリ・インフラのIaC境界が明確になる ~ fujiwara-ware OSS ~ | DevelopersIO
                  • 小さい経路最適化ミドルウェアを実装してあらゆるAZ間通信を削減する - LIFULL Creators Blog

                    KEELチームの相原です。 前回のエントリは「LLMを利用したPlatform Engineering」でした。 www.lifull.blog 今回は、小さい経路最適化ミドルウェアを実装してAZ間通信を削減した話を書きたいと思います。 背景 我々KEELチームはKubernetsベースの内製PaaSであるKEELを開発しており、LIFULLのほとんどのサービスがこのKEEL上で動いています。 www.lifull.blog そして、KEELは巨大なマルチテナントのKubernetesクラスタとしてAWSの複数のAvailability Zone(以下AZ)に展開されていて、多くのmicroservicesが互いに通信しあっています。 そのためAZ間通信はプラットフォームとして重要な関心事の一つです。 レイテンシやAWSのAZ間通信に対する課金を最小限に抑えるため、なるべくAZ間通信を減ら

                      小さい経路最適化ミドルウェアを実装してあらゆるAZ間通信を削減する - LIFULL Creators Blog
                    • インターンの二週間で社内APIを新しく建て本番リリースまで何でもやった話【ソフトウェアエンジニアインターン参戦記】 - エムスリーテックブログ

                      はじめまして。河村 (@KowerKoint2010)です。 この夏、エンジニアリンググループ AI・機械学習チームで2週間の新卒ソフトウェアエンジニアインターンに参加しました。 インターンでは、「Yucca」という内部サービスの改善を担当しました。 当初与えられた課題については設計・開発から本番環境へのリリース、そしてユーザーへの利用法説明まで行い、まだ時間に余裕があったので追加でデータベースの改善も検討しました!*1 ここでは私がやったことを簡単に紹介しつつ、エムスリーという会社で働いてみた感想を伝えます。 エムスリーでのインターンや就職を考えている他の学生の参考になれることを願っています。 最終日にエムスリークリアファイルをプレゼントしたときの様子 Yuccaについて簡単に紹介 BigQueryに特定のフォーマットでデータを置くと、それをクローリングしてきて自動でAPIとして提供する

                        インターンの二週間で社内APIを新しく建て本番リリースまで何でもやった話【ソフトウェアエンジニアインターン参戦記】 - エムスリーテックブログ
                      • Kubernetesパターン 第2版

                        TOPICS System/Network 発行年月日 2024年09月 PRINT LENGTH 392 ISBN 978-4-8144-0088-1 原書 Kubernetes Patterns, 2nd Edition FORMAT Print PDF EPUB マイクロサービスとコンテナの進化に伴い、開発者がソフトウェアを設計、構築、実行する方法は大きく変わりました。これらのアーキテクチャは、分散システムの新しい構成要素を提供し、多くの開発者やアーキテクトが慣れ親しんだものとは異なる一連のプラクティスを必要とします。本書は、Kubernetes上でクラウドネイティブアプリケーションを設計および実装するための再利用可能なパターンを解説します。 はじめに、コンテナベースのクラウドネイティブなアプリケーションを作るための基本原理とプラクティスを紹介し、コンテナとプラットフォーム間の様々な

                          Kubernetesパターン 第2版
                        • The Future of WebAssembly Through the Eyes of a Veteran Kubernetes Engineer | HackerNoon

                          Too Long; Didn't ReadTaylor Thomas is the Head of Engineering at Cosmonic. He was a core maintainer of Helm for 4 years, and co-creator of Bindle and Krustlet. He is now a contributor to, and maintainer of, CNCF wasmCloud and is helping to bring the Cosmonic distributed application development platform to market. At the Pasadena leg of Kubernetes Community Days (co-located with SCaLE 20x), I had t

                            The Future of WebAssembly Through the Eyes of a Veteran Kubernetes Engineer | HackerNoon
                          • Flaggerでも手動カナリアリリースがしたい! - ZOZO TECH BLOG

                            はじめに こんにちは。株式会社ZOZOのSRE部プラットフォームSREチームに所属しているはっちーと申します。 本記事では、Kubernetesクラスター上で自動カナリアリリース機能を提供するFlaggerが導入済みのマイクロサービスにおいて、手動カナリアリリースを実施する方法について紹介します。一見、矛盾するように思えるかもしれません。しかし、時にはそのような要件も発生することがあります。また、手動カナリアリリースで運用している状態からFlaggerの導入を検討している場合、導入後も念のために現行の手動カナリアリリースができるのか、という点は気になるかと思います。すでにFlaggerを導入している、これからの導入を検討している、という方の参考になりましたら幸いです。 目次 はじめに 目次 前提知識(Flagger) Manual Gatingの基本 Manual Gatingとは Man

                              Flaggerでも手動カナリアリリースがしたい! - ZOZO TECH BLOG
                            • Karpenter の魅力と実装にちょっぴり Dive Deep ~ Consolidation 編 ~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

                              こんにちは、ソリューションアーキテクトのごとけん (@kennygt51) です。 皆さま、Karpenter というツールをご存知でしょうか? Karpenter は AWS によって開発された Kubernetes クラスターオートスケーラーです。Kubernetes におけるノードのオートスケールを実現するために、Amazon EKS をご利用の多くのお客様が Karpenter を活用しています。 2021 年にリリースされた Karpenter は、多くのコントリビューターの協力もあって、日々成長を遂げています。2023 年には alpha 版から beta 版への昇格が発表 され、よりユーザーにとって使いやすく進化しました。そして 2024 年 8 月、ついに Karpenter v1.0.0 がリリースされ、安定版に移行しました。 一方で、Amazon EKS を利用している

                                Karpenter の魅力と実装にちょっぴり Dive Deep ~ Consolidation 編 ~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
                              • Karpenter 1.0 がローンチされました | Amazon Web Services

                                Amazon Web Services ブログ Karpenter 1.0 がローンチされました はじめに 2021 年 11 月、AWS は 新しいオープンソースの Kubernetes クラスターオートスケーリングプロジェクト「Karpenter v0.5」の発表を行いました。当初は Kubernetes の Cluster Autoscaler の柔軟で動的かつ高性能な代替手段として考案されていましたが、その後の約 3 年間で Karpenter は大幅に進化し、完全な機能を備えた Kubernetes ネイティブのノードライフサイクルマネージャーになりました。 このプロジェクトは、業界のリーダー企業によってミッションクリティカルなユースケースに採用されています。自動的に利用率を改善するように設計されたワークロード統合や、ユーザーがクラスター内で Karpenter がノードのライフ

                                  Karpenter 1.0 がローンチされました | Amazon Web Services
                                • Netflix、ワークフローオーケストレーター「Maestro」をオープンソース化 1日に約200万のジョブを完了

                                  Netflixは2024年7月23日(米国時間)、大規模なデータ/ML(機械学習)ワークフローオーケストレーター「Maestro」のオープンソース化を発表した。 Maestroは、大規模なデータ/MLワークフロー(データパイプラインやMLモデルのトレーニングパイプラインなど)を管理するために設計された、スケーラブルなワークフローオーケストレーターだ。リトライ、キューイング、コンピュートエンジンへの分散など、ワークフローのライフサイクル全体を管理する。 ユーザーは、Dockerイメージ、ノートブック、bashスクリプト、SQL、Pythonなど、さまざまな形式でビジネスロジックをパッケージ化できる。有向非巡回グラフ(DAG)のみをサポートする従来のワークフローオーケストレーターとは異なり、Maestroは巡回グラフ、foreachループ、サブワークフロー、条件分岐など処理を繰り返すような複雑

                                    Netflix、ワークフローオーケストレーター「Maestro」をオープンソース化 1日に約200万のジョブを完了
                                  • Kubernetes環境でパケットがドロップされる問題を解決した話 - Cybozu Inside Out | サイボウズエンジニアのブログ

                                    この記事は、CYBOZU SUMMER BLOG FES '24(クラウド基盤本部 Stage)DAY 16 の記事です。 こんにちは、Cloud Platformチームの竹村です。 私たちのチームでは、Necoと呼ばれるKubernetes基盤の開発や運用をしています。 このブログ記事では、大量の通信を行うアプリケーションをKubernetes上で運用する際に発生したネットワーク通信経路の障害に関してお話しします。 障害の概要 Kubernetes基盤を利用するチームから、クラスタ内のDNSサーバで性能問題が発生しているとの相談を受け、調査を開始しました。具体的には以下のような事象が起きていました。 Pod内のアプリケーションから一秒間に数百リクエストの単位でクラスタ内のserviceの名前解決を行うと、no such hostやi/o timeoutといったエラーが頻繁に発生する 障害

                                      Kubernetes環境でパケットがドロップされる問題を解決した話 - Cybozu Inside Out | サイボウズエンジニアのブログ
                                    • Cilium 運用で遭遇した問題とその対応 - Cybozu Inside Out | サイボウズエンジニアのブログ

                                      この記事は、CYBOZU SUMMER BLOG FES '24 (クラウド基盤本部 Stage) DAY 17の記事です。 こんにちは。クラウド基盤本部 Cloud Platform 部で Kubernetes 基盤(Neco)のネットワークを担当している寺嶋です。 Neco の Kubernetes クラスタはネットワークに Cilium を採用しています。 Neco の他のブログは以下を参照してください。 blog.cybozu.io Cilium は 2023 年 10 月に CNCF Graduated Project となった成熟したプロジェクトです。 一方で、大規模な環境で運用する際には性能問題や不具合に遭遇してしまうことがあります。 私たちはそのような Cilium に関連して発生する問題に対して、ツール開発や upstream への貢献などの様々な方法で対処しています。

                                        Cilium 運用で遭遇した問題とその対応 - Cybozu Inside Out | サイボウズエンジニアのブログ
                                      • Ebook連載:『5分x10回で学ぶ 開発者のためのDocker コンテナ入門』第1章 -コンテナとは?#docker #DX #Mirantis #コンテナ - クリエーションライン株式会社

                                        技術的に言えば、コンテナはカーネルのネームスペース・コントロールグループ・root権限とシステムコールの制限によって隔離されたプロセスです。これが何を意味するかは、次章以降で説明します。 その前に、コンテナ化の目的について考えてみましょう。そもそも、なぜプロセスとプロセスを分離するのでしょう?単に同じシステム上でプログラムを同時に走らせるだけではダメなのでしょうか? 特に企業にはプロセス同士を分離する多くの理由があります。例えばセキュリティの観点から、あるプログラムが他のプログラムのデータにアクセスできないように、プロセス分離を考える必要があるかもしれません。またプロセスが root 権限やシステムコールへのアクセス権を持っていないことを明確にする必要があるかもしれません。 あるいは、単純に資源効率やITハイジーン(IT環境の衛生管理)の観点からかもしれません。 あるマシンで、Python

                                          Ebook連載:『5分x10回で学ぶ 開発者のためのDocker コンテナ入門』第1章 -コンテナとは?#docker #DX #Mirantis #コンテナ - クリエーションライン株式会社
                                        • Reclaim the Stack Documentation

                                          We spent 7 months building a Kubernetes based platform to replace Heroku for our SaaS product at mynewsdesk.com. The results were a 90% reduction in costs and a 30% improvement in performance. We also significantly improved developer experience with reduced deploy times and faster / more accessible tooling. We have now open sourced the entire stack, so you can do the same, but in a few days instea

                                            Reclaim the Stack Documentation
                                          • Kubernetesのコンポーネントingress-nginxに重大な脆弱性 推奨される対策は?

                                            ARMOは2024年8月18日(現地時間)、「Kubernetes」の重要なコンポーネントである「ingress-nginx」に重大な脆弱(ぜいじゃく)性(CVE-2024-7646)があると報告した。 この脆弱性が悪用された場合、攻撃者に検証プロセスをバイパスされ、任意のコマンドインジェクションやingress-nginxコントローラーの認証情報にアクセスされてしまう可能性があるため注意が必要だ。 Kubernetesの重要コンポーネントに脆弱性 推奨される対策は? ingress-nginxはKubernetes環境で動作する外部アクセスを管理するためのイングレスコントローラーだ。リバースプロキシおよびロードバランサーとして動作し、受信したHTTPやHTTPSのトラフィックを定義されたルールに基づいて適切なサービスにルーティングする機能を提供する。 CVE-2024-7646は、ing

                                              Kubernetesのコンポーネントingress-nginxに重大な脆弱性 推奨される対策は?
                                            • TerraformとAnsibleで作るさくらのクラウドのKubernetesクラスタ | さくらのナレッジ

                                              CAMPHOR-の上田蒼一朗です。今回は「TerraformとAnsibleで作るさくらのクラウドのKubernetesクラスタ」というテーマでお話しします。よろしくお願いします。 まず自己紹介です。上田蒼一朗と申します。今年から京都大学の大学院生としてやっています。昨年度(2023年度)、未踏スーパークリエータに認定されました。技術領域としては、低レイヤとかインフラとかウェブとか、いろいろ好きで、結構何でもやるという感じです。CAMPHOR-では、これからお話しするKubernetesクラスタの運用をやっていたり、他にもいろいろとソフトウェアの管理をしていたりします。 CAMPHOR-とは まずCAMPHOR-(かんふぁー)がどういう組織なのかを軽くご紹介しようと思います。 CAMPHOR-というのは京都のIT系の学生コミュニティなのですが、京都の古民家を拠点にしているというのが特徴にな

                                                TerraformとAnsibleで作るさくらのクラウドのKubernetesクラスタ | さくらのナレッジ
                                              • My IRC client runs on Kubernetes

                                                IRC has historically been one of the most important chat programs in my life. It's how I met my husband, how I found jobs in the early stages of my career, how I get help with weird Linux arcana that nobody else can really fix, and it's where I socialize with the Internet Illuminati. I use it every day and main reason I use tmux is to attach to that one session with my IRC client in it. However, t

                                                  My IRC client runs on Kubernetes
                                                • eBPF Foundation&LF ResearchがeBPF技術の進化とオープンソースエコシステムへの影響を調査したレポート「eBPFの現状」日本語版を公開

                                                  eBPF Foundation&LF ResearchがeBPF技術の進化とオープンソースエコシステムへの影響を調査したレポート「eBPFの現状」日本語版を公開 こんにちは、吉田です。今回は、eBPF FoundationがLinux Foundation Researchと協力して作成・公開された「The State of eBPF」の日本語版「eBPFの現状」について紹介します。 【参照】eBPF Foundation & LF Research 調査レポート「eBPFの現状」を公開 https://www.linuxfoundation.jp/blog/2024/08/japanese-version-of-the-state-of-ebpf/ eBPF(extended Berkeley Packet Filter)とは、Linuxカーネルのソースコードを修正したりカーネルモジュー

                                                    eBPF Foundation&LF ResearchがeBPF技術の進化とオープンソースエコシステムへの影響を調査したレポート「eBPFの現状」日本語版を公開
                                                  • 勘違いしがちな Kubernetes の Job のリトライの挙動を紐解く - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                    この記事は、CYBOZU SUMMER BLOG FES '24 (クラウド基盤本部 Stage) DAY 9 の記事です。 こんにちは。DBRE チーム の山下です。 サイボウズではサービスを運用する上で多くのバッチ処理を実行しています。 Kubernetes 基盤を利用するにあたって、バッチ処理によく使われるのが Job だと思います。サイボウズでも多くの Job を活用しています。 そんな Kubernetes の Job ですが、リトライに関して想定と異なる挙動が見つかったためコードリーディング、kind での検証の両面から調査しました。 今回は調査によって得られた Kubernetes の Job のリトライの挙動に関する知見をご紹介します。 Job の概要 まずは簡単に Job について説明します。 Job は単発のジョブを実現するための Kubernetes リソースです。

                                                      勘違いしがちな Kubernetes の Job のリトライの挙動を紐解く - Cybozu Inside Out | サイボウズエンジニアのブログ
                                                    • ECSのService Connectを試す記事 - サーバーワークスエンジニアブログ

                                                      前書き 本記事の趣旨 完成イメージ図 本記事で取り扱わないこと 対象読者 デプロイ用のCDK作成 フロントエンドのプロジェクト作成 バックエンドのプロジェクト作成 Dockerfileの編集 app.pyの編集 requirements.txtの編集 AWSのインフラ部分の作成 CDKのデプロイ デプロイ後のリソースの確認 サービス 作成順序について ECSのコンテナ同士の通信関係の表現 バックエンドコンテナの名前解決はどうなっているか? マネジメントコンソールから動作を確認する 負荷をかけて、挙動を確かめてみる。 まとめ 前書き CS1の石井です。 直近の案件でECSを使う構成を検討しており、ECSについて調査していました。 調査中に「Service Connectという設定が、いい感じにサービス同士の通信をやってくれる」という話を聞いて、実際に試して挙動を確認してみたいなぁと思いました

                                                        ECSのService Connectを試す記事 - サーバーワークスエンジニアブログ
                                                      • AWS のサービスに関するベストプラクティスアラームの推奨事項 - Amazon CloudWatch

                                                        CloudWatch は、すぐに使えるアラームの推奨事項を提供します。これらは CloudWatch アラームで、他の AWS のサービスによって公開されるメトリクス用に作成することをお勧めするものです。これらの推奨事項は、モニタリングのベストプラクティスに従うためにアラームを設定すべきメトリクスを特定するのに役立ちます。推奨事項では、設定すべきアラームのしきい値も提案されています。これらの推奨事項に従うことで、AWS インフラストラクチャの重要なモニタリングを見逃さないようにできます。 アラームの推奨事項を見つけるには、CloudWatch コンソールの [メトリクス] セクションを使用し、[アラームの推奨事項] フィルタートグルを選択します。コンソールの [推奨されたアラーム] に移動してから推奨アラームを作成すると、CloudWatch はアラーム設定の一部を事前に入力できます。一部

                                                        • AKSのアップグレード、しんどくない? 「がんばらない」アップグレード方法を考える

                                                          エーピーコミュニケーションズの吉川俊甫氏が、「がんばらない」AKS(Azure Kubernetes Service)のアップグレード方法について、5つ紹介しました。全2回。 AKSのアップグレード、しんどくない? 吉川俊甫氏(以下、吉川):エーピーコミュニケーションズの吉川です。「『がんばらない』AKSアップグレード方法を考えよう」というセッションをお話ししたいと思います。 正直、テクニカルなところは、もう全部真壁さんがしゃべってしまったので、私は、AKSのアップグレードに苦しんでいるみなさんの気持ちに寄り添うエモーショナルな、エモい感じのお話をしようかなと思っています。よろしくお願いします。 ということで、自己紹介です。吉川と申します。先ほどご紹介があったとおり、株式会社エーピーコミュニケーションズに所属していまして、今は、テクニカルエバンジェリストという職種で仕事をしています。 マイ

                                                            AKSのアップグレード、しんどくない? 「がんばらない」アップグレード方法を考える
                                                          • AWSのEKSでターゲットグループのスロースタート期間を設定する|サラトガ牧場

                                                            EKS で pod の起動を遅らせる方法はいくつかあります。 Kubernetes の readinessProbe などで、pod 起動時のヘルスチェックのタイミングを調整をするのも方法の 1 つですよね。 しかし今回は、pod が Ready になった際にいきなりフルフルでアクセスを送り込むのではなく、若干でもいいので緩やかにしたいという状況に遭遇しました。 istio などを使うことも考えられますが、新しく導入せずに対応を検討してみましたので紹介します。 Contents podのリクエスト調整の調査スロースタート期間スロースタート期間の設定一括設定(Ingress)個別設定(Kubernetes – Service)podのリクエスト調整の調査 まず、pod の前段にいるところから調べていきましょう。 pod に近い存在で考えてみると、Kubernetes の service や

                                                              AWSのEKSでターゲットグループのスロースタート期間を設定する|サラトガ牧場
                                                            • 【AWS】Amazon CloudWatch Logs でログ収集をやってみた|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本

                                                              2020.06.23 | Writer:サマタ 【AWS】Amazon CloudWatch Logs でログ収集をやってみた クラウドに関する情報満載のNTT東日本メールマガジンはこちらからご登録ください。 1.はじめに 初めまして、クラウド導入・運用サービスにて構築担当をしているサマタと申します。このようなコラムを記載するのは初めてで至らない点もあるかと思いますが、どうぞよろしくお願いいたします。 今回のコラムでは、AWSの運用サービスでも主要なAmazon CloudWatch(以下、CloudWatch)機能のひとつである、Amazon CloudWatch Logs(以下、CloudWatch Logs)についてご紹介したいと思います。 オンプレミス環境と同様に、AWS環境にインスタンスを構築した際も、サーバやアプリケーションのログ収集を行いたいという要望は多いのではないでしょう

                                                                【AWS】Amazon CloudWatch Logs でログ収集をやってみた|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本
                                                              • ECS(Fargate)上に構築したLocustからAPIサーバ(Go)経由で、TiDB Cloudにクエリを実行してみた | DevelopersIO

                                                                package main import ( "database/sql" "log" "net/http" "crypto/tls" "github.com/go-sql-driver/mysql" ) // 起動するポート const port = "8080" func helloHandler(w http.ResponseWriter, r *http.Request) { // データベース接続 // TiDB Cloudにて表示されたコード mysql.RegisterTLSConfig("tidb", &tls.Config{ MinVersion: tls.VersionTLS12, ServerName: "gateway01.ap-northeast-1.prod.aws.tidbcloud.com", }) db, err := sql.Open("mysql", "

                                                                  ECS(Fargate)上に構築したLocustからAPIサーバ(Go)経由で、TiDB Cloudにクエリを実行してみた | DevelopersIO
                                                                • はじめに|Ginkgo/GomegaによるKubernetes Operatorのテスト手法

                                                                    はじめに|Ginkgo/GomegaによるKubernetes Operatorのテスト手法
                                                                  • KubeDay Japan 参加レポート | sreake.com | 株式会社スリーシェイク

                                                                    はじめに こんにちは!3-shakeで DevRel をやっている横尾(@866mfs)です。 2024/08/27 に開催された、KubeDay Japan に参加してきましたので、参加レポートとして現地の状況をお伝えしようと思います! ここでは、参加レポートとして現地の内容を中心に投稿させて頂こうと思うので、技術的な内容の深掘りはまた別の機会でお楽しみください 🔈 KubeDay Japanとは? CNCF が主催する本イベントは、2年ぶりにリアル開催となります。 グローバル・日本のエキスパートと、ユーザーやシステム開発に関わるエンジニアとのコラボレーションを促進し、Kubernetes を中心としたクラウドネイティブの最新動向を把握できるようなセッションをたくさん聴くことができます。 会場には、CNCJ オーガナイザーの方々をはじめとする多くの来場者が訪れ、 3-shake の技術

                                                                    • Argo RolloutsがProgressDeadlineExceededなとき自動でRestartする仕組みを作った話 - pixiv inside

                                                                      はじめに こんにちは。インフラ部のlyluckです。 この記事ではArgo RolloutsのRolloutがProgressDeadlineExceededによってDegradedになってしまう現象と、その対策について紹介します。 背景 ピクシブではKubernetesクラスタ内の一部のアプリでArgo RolloutsのRolloutを使ってblue-greenデプロイをしています。 Argo Rolloutsとはblue-greenデプロイや、canaryデプロイなどの便利なデプロイ機能をKubernetesに追加してくれるツールです。その中心となるリソースがRolloutです。Podの数を管理するという点でDeploymentと似ていますがデプロイの戦略が選べたり、細かなデプロイステップの制御ができたりします。 Argo Rolloutsをv1.7.1にバージョンアップしたところ、

                                                                        Argo RolloutsがProgressDeadlineExceededなとき自動でRestartする仕組みを作った話 - pixiv inside
                                                                      • ECS(Fargate)上にLocustとAPIサーバ(Go)を構築してService Connectで接続してみた | DevelopersIO

                                                                        こんにちは、ゲームソリューション部のsoraです。 今回は、ECS(Fargate)上にLocustとAPIサーバ(Go)を構築してService Connectで接続してみたことについて書いていきます。 イメージの作成 LocustとLocustのリクエスト先のAPIサーバのイメージを作成します。 Locust Locustのdockerfileは以下です。 FROM locustio/locust WORKDIR /locust # Locustのシナリオファイルを配置 COPY locustfile.py /locust/locustfile.py # Locustのシナリオを実行 CMD ["-f", "/locust/locustfile.py"]

                                                                          ECS(Fargate)上にLocustとAPIサーバ(Go)を構築してService Connectで接続してみた | DevelopersIO
                                                                        • 【Kubernetes】Kustomizeでベースマニフェストの特定のリソースを削除する|サラトガ牧場

                                                                          Kubernetes で複数の環境を管理する場合、ベースとなる manifest を作成して、それを各環境で上書きするケースが多いと思います。 上書きはそれでいいのですが、特定のリソースを無効化したい場合はどうしたらいいのでしょうか。 今回は、特定のリソースを削除する方法を紹介します。 Contents manifestのベース設定特定のリソースを削除するkustomize.yamlの定義を駆使するpdb.yamlの定義で打ち消すmanifestのベース設定 例えば、manifest のベースファイルの kustomization.yaml で、以下のリソースを構成していると仮定します。 ・ConfigMap ・Deployment ・HorizontalPodAutoscaler(HPA) ・PodDisruptionBudget(PDB) ・Service CPU やメモリのリソース、

                                                                            【Kubernetes】Kustomizeでベースマニフェストの特定のリソースを削除する|サラトガ牧場
                                                                          1