並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 791件

新着順 人気順

ecsの検索結果1 - 40 件 / 791件

  • 『呪術廻戦 ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化 - Sumzap Engineering Blog

    この記事は、2024年3月7日に開催された「CyberAgent Game Conference 2024(CAGC 2024)」のセッション内容をAIによる自動文字起こしをベースに加筆修正したものになります。 セッション概要 TVアニメ『呪術廻戦』初のスマホゲーム『呪術廻戦 ファントムパレード(ファンパレ)』は、多くのユーザーに遊ばれ大量のアクセスが来ることが予想されていました。 本セッションでは、高負荷が予想される中、どのようにインフラを構築し負荷対策を行ったのか、実際のインフラ構成図をお見せしながらお話しします。 また、アプリリリース前に行った負荷試験の流れや、リリース後の負荷状況について、具体的なメトリクスの数字をお見せしながらご紹介します。 ※セッションのアーカイブ動画 登壇内容 タイトル 『呪術廻戦 ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化というタイトル

      『呪術廻戦 ファントムパレード』の大規模アクセスを支えるインフラ構成と最適化 - Sumzap Engineering Blog
    • LogLog Games

      The article is also available in Chinese. Disclaimer: This post is a very long collection of thoughts and problems I've had over the years, and also addresses some of the arguments I've been repeatedly told. This post expresses my opinion the has been formed over using Rust for gamedev for many thousands of hours over many years, and multiple finished games. This isn't meant to brag or indicate su

      • AWS 導入事例: ニンテンドーシステムズ株式会社 | AWS

        ニンテンドーアカウント、ゲームニュースなど、任天堂が展開するネットワークサービスの開発・運用を担うニンテンドーシステムズ。インターネット経由でソフトウェアのダウンロードや追加コンテンツなどを購入できるオンラインショップ『Nintendo eShop』は、同社が手がけるサービスの 1つです。 Nintendo eShop は 2011 年に始まり、現在は世界中で 1 億 3,000 万台以上の販売実績を持つ Nintendo Switch に対して、40 か国以上の国に 24 時間 365 日の体制でサービスを提供しています。任天堂のデジタルコンテンツの総売上は 2017 年から 2023 年にかけて 10 倍以上となり、現在はゲームソフトの売上高全体に占めるデジタル比率は 50% 近くに達しています。 Nintendo eShop の基盤は当初オンプレミスで運用してきましたが、利用者が急増

          AWS 導入事例: ニンテンドーシステムズ株式会社 | AWS
        • スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)

          TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ?と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので

            スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)
          • pull requestを利用したいい感じのECS feature環境管理方法を考えた - Nealle Developer's Blog

            はじめに SREチームの大木です。スノボの季節がもう終わりかけており、さみしい限りです。 feature staging環境*( 以下 feature環境 )自体のライフサイクルや管理をどうするか問題、なかなかどこも苦労していると思いますが、その中で今回それなりにいい感じの回答を出せたと思うので共有したいと思います。 *呼び方はpre-staging環境、pull request環境、テスト環境などいろいろありそうですが、私たちはfeature環境と呼んでいます。 どこが「いい感じ」なのかというと、PRのラベル付与によって環境の生成/削除を制御できる点です。PR画面上で楽々とfeature環境の管理ができたり、PR一覧からどのブランチでfeature環境が立っているかが分かりやすくなります。 feature環境について feature環境を当社のプロダクトであるPark Directの開発

              pull requestを利用したいい感じのECS feature環境管理方法を考えた - Nealle Developer's Blog
            • AWS ECS Fargateは1分間にいくつまで数えられるか-Linux/ARM64とLinux/X86_64の性能比較

              AWS Graviton2 プロセッサは、64 ビットの Arm Neoverse コアを使用してアマゾンウェブサービスがカスタムビルドしたもので、Graviton2 を搭載した Fargate は、同等のインテル x86 ベースの Fargate に比べて、最大 40% の料金性能向上と 20% の低コストを実現し、

                AWS ECS Fargateは1分間にいくつまで数えられるか-Linux/ARM64とLinux/X86_64の性能比較
              • 【AWS】障害時の調査事項まとめ ~ELB・ECS・RDS~ - Qiita

                はじめに 現在はAWSで構築されたシステムの運用保守業務に携わっており、その一環として障害調査を行うことが多々あります。 少しは経験値が上がったため、障害が発生した際に初動で確認する事項をまとめてみました。 インフラ基盤観点で障害調査を行うさいの参考になれば幸いです。 前提条件 当システムの構成は以下となっているため、それに即した調査項目となっています。 ALB/NLB・ECS・RDSを利用している ECSはEC2上で実行している(Fargateでは利用していない) ECSクラスター(以下クラスター)の自動スケーリング設定をしている ECS サービス(以下サービス)の自動スケーリング設定をしている RDSはAuroraを利用している また、障害は予期せぬコンテナの停止を想定しています。 NLB/ALBの調査事項 メトリクス 初めにロードバランサーのメトリクスからターゲットの状態を確認します

                  【AWS】障害時の調査事項まとめ ~ELB・ECS・RDS~ - Qiita
                • Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog

                  SREチームの橋本です。SRE連載の3月号となります。 Amazon ECSのコスト最適化においてはFargate Spotが有効な手段となりますが、いつ中断されるか分からない性質上、その監視も併せて実施していく必要があります。今回はそのFargate Spotを本番環境で運用しているプロジェクトにおける取り組みを紹介します。 背景 Fargate (Amazon ECS on AWS Fargate) を用いると負荷に合わせた容易なスケーリングが可能になる一方、このときCPU使用率の安全マージンや予測のブレなどにより、リソースがやや過剰になってしまうこともあります。 Fargate Spotの代表的なユースケースと言えばユーザーに露出しない開発環境ではないかと思いますが、このような場合にコストを考えると、タスクの中断をある程度許容しての本番環境でのFargate Spot運用も可能な選択

                    Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog
                  • [ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media

                    この記事について みなさん、ECS利用していますか!? AWSでコンテナを使うのなら、ECSですよね!?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが1つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル(以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく

                      [ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
                    • AWS CDKでECS Fargate Bastionを一撃で作ってみた | DevelopersIO

                      EC2インスタンスの踏み台を用意したくない こんにちは、のんピ(@non____97)です。 皆さんはEC2インスタンスの踏み台を用意したくないと思ったことはありますか? 私はあります。 VPC上のRDS DBインスタンスやRedisクラスター、OpenSearch Service ドメインなどのリソースに接続したい場合、Site-to-Site VPNやClient VPN、Direct Connectがなければ踏み台(Bastion)が必要になります。 踏み台へのアクセス方法は以下のようなものがあります。 直接SSH SSMセッションマネージャー EC2 Instance Connect そして、踏み台となるリソースとして採用される多くがEC2インスタンスだと考えます。EC2インスタンスの場合、OS周りの面倒をみる必要があります。OS内のパッケージのアップデートが面倒であれば「踏み台が

                        AWS CDKでECS Fargate Bastionを一撃で作ってみた | DevelopersIO
                      • ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products

                        3年ほど前に登場した比較的新しいサービスであるApp Runnerを商用環境で導入した事例を紹介します。 インフラの運用の手間を軽量化できる一方で、利用して初めて気づく課題もありました。 本日は実際の導入事例に基づいて、ECS Fargateとの比較、CI/CD・監視の工夫から障害発生時の運用方法といった生の体験を紹介することで、これから導入を考えている方へ向けて、技術選定のポイントとなる"肌感"を共有できればと思います。 登壇アーカイブ:https://www.youtube.com/watch?v=YiE3n06tfCA

                          ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products
                        • Solrのクラウド移行 -AWS ECS Fargateの事例- - LIVESENSE ENGINEER BLOG

                          はじめに 技術部インフラグループの春日です。 2024年現在、弊社が運営している マッハバイト は一部を除いてオンプレからクラウドへの移行が完了しました。 本記事では移行対象の1つであった Apache Solr に関する総括をします。 今回のプロジェクトでは移行自体を最優先とするため、スコープを以下に定めていました。 Apache Solrから他の検索エンジンへは乗り換えない アプリケーション側の改修は向き先の変更だけに留める Apache Solr自体のバージョンUP対応はしない 運用負荷を軽減できる形の構成変更を加える 移行スピードと移行後の運用コストとの天秤 新たに運用しないといけなくなるコンポーネントはなるべく増やさない モニタリングや監視の精度はなるべく落とさない 上記を踏まえ、以降の節ではApache Solrのサービス内利用箇所の紹介から始め、 インフラ構成・デプロイ・モニ

                            Solrのクラウド移行 -AWS ECS Fargateの事例- - LIVESENSE ENGINEER BLOG
                          • [ アップデート ] aws_ecs_task_definition に CI/CD との競合を防ぐ track_latest 引数がリリースされました | DevelopersIO

                            [ アップデート ] aws_ecs_task_definition に CI/CD との競合を防ぐ track_latest 引数がリリースされました aws_ecs_task_definition を定義する際、いつも指定しているあの ignore_changes が、不要になるかもしれません。 tfstate への反映、コードとの差分があった場合の挙動に違いがあるため、理解しておくと今後役立つかもです。 こんにちは! AWS 事業本部コンサルティング部のたかくに(@takakuni_)です。 aws_ecs_task_definition で CI/CD との競合を防ぐために、 track_latest 引数がリリースされました。 r/aws_ecs_task_definition: add track_latest attribute by GerardSoleCa · Pull

                              [ アップデート ] aws_ecs_task_definition に CI/CD との競合を防ぐ track_latest 引数がリリースされました | DevelopersIO
                            • 日本CTO協会による合同ISUCON研修の紹介 - Pepabo Tech Portal

                              こんにちは!技術部プラットフォームグループのharukin, pochyです。 この記事では、「ISUCON」を模したパフォーマンスチューニング研修を複数社合同で実施した概要と、そのための準備について紹介します。 研修について 目的 今回の研修の目的は次のものとしました。 パフォーマンスチューニングの問題を会社横断でチームを組成し取り組むことで、サーバサイドやインフラのパフォーマンス・チューニングを中心に幅広い知識を総動員して課題解決に望む。 課題解決過程のコミュニケーションを通じて、会社の枠を超えた同期作りを促進する。 概要 今回の研修では、チームごとにパフォーマンスチューニングの課題に挑戦しました。 実際のISUCONのように、各チームにwebサーバーを貸し出す形式です。各チームはそのアプリケーションを時間内にパフォーマンスチューニングし、最適化された度合いによってチームに点数をつけま

                                日本CTO協会による合同ISUCON研修の紹介 - Pepabo Tech Portal
                              • Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024

                                https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17

                                  Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
                                • Scheduled tasks(ECS)をecscheduleで管理してみた - NRIネットコムBlog

                                  本記事は 基盤デザインウィーク 8日目の記事です。 🌈 7日目 ▶▶ 本記事 ▶▶ 9日目 💻 はじめに ecscheduleとは 「スケジュールされたタスク」 Amazon EventBridgeについて 構成図 コード体系 ecschedule.yaml target.json 構築手順 0. 前提 1. 必要リソース構築(dev) 2. ecschedule dump(dev) 3. 設定ファイルの修正 4. ecschedule apply(prod) 検証中にハマったポイント 1. ecschedule dumpコマンドが成功しない 2. 別リージョンからtfstateの読み込みは出来ない 3. サブコマンドからリソース削除が出来ない まとめ はじめに こんにちは、加藤です。 以前ecspressoについての記事を書きました☕️ tech.nri-net.com 今回はecs

                                    Scheduled tasks(ECS)をecscheduleで管理してみた - NRIネットコムBlog
                                  • Dive deep into Amazon ECR (ECRの裏側の仕組みを知ろう)

                                    Amazon ECR とは コンテナのワークフローとレジストリの役割 コンテナをベースとしたワークフローを組んだ場合、「Build, Ship, Run」に基づき整理すると下記にようになります。 アプリケーションのソースコードとDockerfileというコンテナイメージを構築するためのファイルを用意し、イメージを作成していきます。 Dockerfileというのは、このファイル上にコマンドを記述することで、アプリケーションに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定する役割を持ちます。 さて、ここで重要になってくるのはこのコンテナイメージを保存する先ですね。 そこで出てくるのが、レジストリと呼ばれるものです。 レジストリとは、コンテナイメージを保存するサービスで、Dockerレジストリを基点としてさまざまなプラットフォームにイメージを配布したり、利用者間でイメージを共有

                                      Dive deep into Amazon ECR (ECRの裏側の仕組みを知ろう)
                                    • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

                                      これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr

                                        AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
                                      • Amazon ECS and AWS Fargate now integrate with Amazon EBS

                                        Amazon Elastic Container Service (Amazon ECS) and AWS Fargate now integrate with Amazon Elastic Block Store (EBS), allowing you to easily provision and attach EBS volumes to Amazon ECS tasks running on both AWS Fargate and Amazon Elastic Compute Cloud (EC2) using Amazon ECS APIs. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media trans

                                          Amazon ECS and AWS Fargate now integrate with Amazon EBS
                                        • freeeサインのAWSリージョンを移行した話 - freee Developers Hub

                                          この記事はfreee 基盤チーム Advent Calendar 2023 の24日目の記事です。 はじめに はじめまして! kanno と申します。freee SREで、freeeサインのプロダクトSREを担当しておりAWSインフラの改善や運用を主に行っています。初回の投稿で拙い文章になりますが、直近で実施したfreeeサインのAWSリージョンを移行した話を書こうと思います。 背景 元々、freeeサイン(旧ninja-sign)はHeroku上にアプリケーションをデプロイしていましたが、2022年の年末頃にAWSに移行しています。その際、元々のHerokuがus上で稼働していたことが影響して、AWSのバージニアリージョンに移行された状態でした。私がfreeeのサインチームにjoinしたのがこの時で、AWSリージョン移行を担当することになりました。 AWSリージョン移行のモチベーション

                                            freeeサインのAWSリージョンを移行した話 - freee Developers Hub
                                          • EC2とcronで動いていたバッチ基盤をマネージド化した - Uzabase for Engineers

                                            概要 ソーシャル経済メディア「NewsPicks」SREチームの中川です。 皆さんはバッチ処理基盤はどうされていますでしょうか。 NewsPicks では少し前まではそれらをEC2、cronの組み合わせで動作させていました。 何年も前からこの仕組みだったのですがSREとしてはEC2の面倒見るのも手間ですし、それ以上にcronを変更する際のオペレーションミスが目立ったのが懸念点でした。 その為、まずはAWSマネージド化するための基盤を整備し、その後バッチアプリを載せ替えていくようにしました。 対応前の基盤構成 同じSREチームの安藤さんが CloudNative Days Tokyo 2023 で登壇されたときの資料をお借りします。 ご覧の通り、大体のサービスはマネージド化していましたがバッチ基盤だけは旧来のままEC2インスタンスを利用していました。 10年モノのサービスのインフラを漸進的

                                              EC2とcronで動いていたバッチ基盤をマネージド化した - Uzabase for Engineers
                                            • あらためて、じっくり動かすFargate

                                              自分でECS/Fargateやその周辺リソースのインフラ構築・整備をしたり、まわりのインフラ強くないチームメンバーがデバッグに苦戦する様子を見ながら、やっぱりECSは登場するリソースがちと多かったり役割分担がとっつきにくかったりするよなぁと思っていました。 漠然とそんなことを思っていた頃、社内で自分の属するグループに勉強会が爆誕し「これはECSの話するしかないのでは」と思い立ち...そのまま2ヶ月ほど経過してしまいました。というわけで社内アドベントカレンダーに登録し、締切駆動執筆することにしました。というわけで この記事は LITALICO Engineers Advent Calendar 2023 の18日目の記事です。 はじめに この記事では、ECS、特にFargateを使ったWebサーバの構築を、基礎からハンズオン的に組み上げていく内容になっています。ECSタスクやタスク定義、サー

                                                あらためて、じっくり動かすFargate
                                              • Amazon ECSタスクを冪等に起動できるようになりました | DevelopersIO

                                                旧聞ですが、2023/11/13からAmazon ECSが冪等なタスク起動をサポートし、副作用無しに再試行、複数回呼び出せるようになりました。 現時点では、以下のECS APIが冪等性をサポートしています。 CreateService CreateTaskSet RunTask 冪等性を実現する場合、主に次の2通りがあります。 複数回呼び出される前提で、アプリを冪等に実装 一度しか呼び出されない前提で、アプリをシンプルに実装 Amazon SQSを例に取ると、at least onceなスタンダードキューが前者で、exactly onceなFIFOが後者です。 今回のECSアップデートは後者です。ECSタスクの冪等起動対応により、ライブラリ・フレームワークの力を借りながら頑張って冪等に実装していたタスクを、シンプルに実装できるようになることがで期待できます。 ポイント 重要なポイントを述べ

                                                  Amazon ECSタスクを冪等に起動できるようになりました | DevelopersIO
                                                • Amazon ECSにおけるカナリアリリースの実現

                                                  カナリアリリースに関連のある部分を図に起こしたものが以下です。 ECSクラスターの中にあるサービスに対してターゲットグループを設定し、ALBからのリクエストをタスクに割り振っています。 デプロイはGitHub ActionsのWorkflow Dispatchを使用し、ボタン押下で実行できます。このプロセスはDockerイメージをビルド、Amazon Elastic Container Registry(以下、Amazon ECRと表記)にイメージをプッシュし、Amazon ECSのタスク定義を更新すると自動的にタスクのローリングアップデートが走る仕組みを使用しています。 余談ですが、クーポンサービスでは以前Spring Boot 2.6を採用していました。 Spring Bootの3系へのアップグレードについては記事「出前館クーポンサービスでのサーバーアプリケーションのSpring Bo

                                                    Amazon ECSにおけるカナリアリリースの実現
                                                  • 2023年のSREチームのAWSコスト削減を振り返る - Uzabase for Engineers

                                                    概要 全般 何はともあれコストタグ Cost Explorer でリソース別にコストを見よう IaC化しよう QuickSight も使おう 稼働時間対応する際はマスタカレンダを用意したい コンピューティング、コンテナ関連 EC2 定時バッチはマネージド化しよう EBS, Snapshot, AMI, EIP を消す ECS Container Insights の有効/無効を使い分けよう 何でも Fargate を選択すれば良いわけではない Fargate スポットを活用しよう Lambda Graviton対応しよう ECR イメージサイズを抑えよう ライフサイクルポリシーを設定しよう ネットワーキング VPC VPCエンドポイント入れ忘れに注意 VPC Flow Logs のS3バケット設定に注意しよう ストレージ系 RDS スロークエリ出てないかAPMを使って確認 DynamoDB

                                                      2023年のSREチームのAWSコスト削減を振り返る - Uzabase for Engineers
                                                    • dbtでCIを実現するために、Github ActionsでAWSのVPC越えしたい。 - KAYAC engineers' blog

                                                      この記事はTech KAYAC Advent Calendar 2023の8日目の記事です。 こんにちわ。その他事業部SREチームの@mashiikeです。 最近、風変わりな記事を連投しているのですが、今回も風変わりです。 ひとことで要約すると、 私は!Github Actionsから!Redshiftにアクセスしたいんだ!!! です。 TL;DR dbtのCIを実現したい。ローカルのunit-testはできてるんだが、Github ActionsからRedshiftへのアクセスに難がある。 Github ActionsからRedshiftにアクセスするために頑張ってみた。 kayac/ecspressoで踏み台となるECS Taskを立ち上げる。 fujiwara/ecstaでportforwardingする。 mashiike/redshift-credentials で一時認証情報を

                                                        dbtでCIを実現するために、Github ActionsでAWSのVPC越えしたい。 - KAYAC engineers' blog
                                                      • ECSの可用性設計を4つの軸で整理する | sreake.com | 株式会社スリーシェイク

                                                        はじめに こんにちは!Sreake事業部 志羅山です。今年3月に3-shakeに入社し、長野県からリモートで仕事をしています(東京にも定期的に行ってます)。 最近、とあるお客様環境におけるECS(AWSのフルマネージド型コンテナオーケストレーションサービス)の利用方針を整備する中で、ECSの可用性に関する設計要素について調査・整理する機会がありました。今回この記事ではその内容を紹介したいと思います。 整理してみて感じたこととして、「思ったよりも考えることが多く、やや複雑で奥深い」という印象を受けました。同じように感じている方にとって参考になれば幸いです。 当記事の目的と書くこと この記事は「ECSの可用性に関する設計要素や考慮事項の体系がややぼんやりしている」という読者の方に「全体のイメージが何となくつかめた」と感じてもらえることを目的としています。 そのために、「ECSの可用性設計要素」

                                                          ECSの可用性設計を4つの軸で整理する | sreake.com | 株式会社スリーシェイク
                                                        • AI・機械学習チーム流MLOpsの歴史 - エムスリーテックブログ

                                                          エムスリー Advent Calendar 2023 五日目担当、AI・機械学習チームの横本(yokomotod)です。前日は同じくAIチーム大垣さん(id:Hi_king)からの「画像を理解するGPT-4 Visionで、既存の画像認識モデルを説明可能にする」でした。 たまたま並んでしまいましたが、昨日のAIチームのMLエンジニアリングな話に続けて、今日はMLOpsやインフラについてのお話です。 (さらに本日はmabl Advent Calendar 2023としてQAチームの城本さん(@yuki_shiro_823)から「mabl Experience'23で「複数チームでmablを活用する際の課題と対応」について話しました 」も公開されています!) どうやらエムスリーAIチームも2017年の発足からもう6年が経過しているようです。 私がチームに参加したのは2019年ごろですが、見てき

                                                            AI・機械学習チーム流MLOpsの歴史 - エムスリーテックブログ
                                                          • コスト削減で重要な「ボトルネックから潰す」「覚悟を持つ」 約60,000ドル削減のため、具体的に実行した6つのこと

                                                            「Startup Day 2023」は日本中のAWSを利用するStartupが、AWSの知見を披露するHubとなる1日です。2023年はサブテーマに「スタートアップ冬の時代を共に乗り越える」を掲げて、スタートアップが面しているこの逆境をどうやって跳ね除け、成長につなげていけるかを共有します。ここで、株式会社SODAの林氏が登壇。ここからはコスト削減のために具体的に実行したことについて話します。前回はこちらから。 コスト削減のために実行したこと1 VPC Endpointの導入 林雅也氏:ここまでどういうふうにコストを削減していくかの方針を見ていったので、それに沿って、実際に「SNKRDUNK」(以下、スニダン)でどのようなコスト削減が行われてきたのかをお話しします。 方針で言っていたとおり、まずはもちろんボトルネックを探すところからです。(スライドを示して)こちらの図は、コスト削減の取り組

                                                              コスト削減で重要な「ボトルネックから潰す」「覚悟を持つ」 約60,000ドル削減のため、具体的に実行した6つのこと
                                                            • [アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent | DevelopersIO

                                                              [アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent ついにECS on Fargateでコンテナランタイムのセキュリティ対策ができるようになりました!Fargate利用者は全員必見のアップデートです! こんにちは。AWS事業本部トクヤマシュンです。 本日より、Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました!! 当機能はECS on Fargate、ECS on EC2のどちらにも対応しています!! (2023/11/29追記:ECS on EC2は現在プレビュー機能のようです。) 立ち位置としては、これまでAmazon GuardDuty EKS Runtime MonitoringとしてEKSのみに提供されてきた機能が、 Runti

                                                                [アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent | DevelopersIO
                                                              • 改めてCI/CDパイプラインを使ったECS自動デプロイの流れを整理する - NRIネットコムBlog

                                                                本記事は 【コンテナウィーク】 1日目の記事です。 💻 告知記事 ▶▶ 本記事 ▶▶ 2日目 📱 こんにちは。梅原です。 皆さんはCI/CDパイプラインやってますか。昨今はパイプラインファーストという考え方もあり、ソースコードの変更反映をトリガーにテストやビルド、デプロイまで自動でやることは多いのではないでしょうか。 今回はAWSでCI/CDパイプラインを実現するためのサービスであるCodeシリーズ(CodeCommit、CodeBuild、CodeDeploy、CodePipeline)を使ってECSへ自動デプロイする流れを見ていきます。 AWSでCI/CDパイプラインを実現するために そもそもCI/CDパイプラインは、継続的インテグレーション/継続的デリバリーの略で、これまで手動でしていたテストやビルド、デプロイ作業を自動化・高速化するために使われるものです。 CI/CDパイプライ

                                                                  改めてCI/CDパイプラインを使ったECS自動デプロイの流れを整理する - NRIネットコムBlog
                                                                • Amazon ECS が、予測不可能な負荷のスパイクに対するアプリケーションの回復性を向上

                                                                  本日、Amazon Elastic Container Service (Amazon ECS) はタスクスケジューリングを強化し、予測不可能な負荷のスパイクに対するアプリケーションの回復性をさらに向上させました。Amazon ECS は、コンテナまたはロードバランサーのヘルスチェックに合格しなかった異常なタスクを終了する前に、正常な代替タスクを開始するようになりました。この機能の強化により、追加の作業や構成なしで、お客様のアプリケーションの回復性が向上します。 Amazon ECS はフルマネージドのコンテナオーケストレーションサービスで、非常に安全で、信頼性が高く、スケーラブルなコンテナ化アプリケーションを簡単に実行できます。お客様はアプリケーションのコンテナまたはロードバランサーのヘルスチェックを定義して、異常のあるタスクをいつ終了して新しいタスクに置き換えるべきかを Amazon

                                                                    Amazon ECS が、予測不可能な負荷のスパイクに対するアプリケーションの回復性を向上
                                                                  • 税理士ドットコム流のCI/CDを設計する考え方と実践 - 弁護士ドットコム株式会社 Creators’ blog

                                                                    今年の頭から税理士ドットコム事業部に異動した @komtaki です。3 月末から 7 月まで育休を頂いていたのですが、無事復帰しました。 部署異動してすぐに、ジョブ追加の際にコンテナや CI/CD の最適化がされず開発体験を損なっていると感じました。そこで、異動直後の 2 月末に、フルスクラッチでコンテナと CI/CD を作り直しました。 約半年運用し GitLab CI でのデプロイ運用のデータが溜まり、定量的にデプロイを分析できるようになりました。 そこで税理士ドットコムのデプロイフローにどのような問題があったのか、CI/CD の設計の考え方と改善後の効果についてお話しします。 CI/CDとは 簡単におさらいすると、CI/CD とはソフトウェアの変更を常にテストし、自動で本番環境へ適用できるような状態にしておく開発手法です。CI/CD がうまく機能した場合、下記のような効果があります

                                                                      税理士ドットコム流のCI/CDを設計する考え方と実践 - 弁護士ドットコム株式会社 Creators’ blog
                                                                    • AWS Fargate、Amazon ECSの起動と停止を自動化できる無料ツールを紹介します | DevelopersIO

                                                                      はじめに 弊社が提供する無料のAWS運用かんたん自動化ツール「opswitch」を使って、夜間や土日祝日などの使わない時間帯に開発環境のAWS Fargate、Amazon ECSを停止させる方法を紹介します。プログラムなどの知識はなくても、Webの操作だけで設定を行えます。Fargateを例に説明をすすめます。ECS(ECS on EC2)の場合は「タスクの作成」が少し違いますので補足をご覧ください。 準備 ユーザーガイド opswitchを開始するを参考に以下の初期設定を完了させてください。 opswitchのアカウント作成 opswitchアカウントの初期設定 ユーザー属性情報登録 組織作成 AWSアカウント連携作成 タスクの作成 それではFargateを起動させるタスクから作成します。 Management Consoleでタスク数を変更したいECSサービスにタグをつけます。どのサ

                                                                        AWS Fargate、Amazon ECSの起動と停止を自動化できる無料ツールを紹介します | DevelopersIO
                                                                      • Amazon ECS の古いタスク定義を断捨離する "tdtidy" という隙間家具 OSS を作った | はったりエンジニアの備忘録

                                                                        自分は Amazon ECS のデプロイに ecspresso を利用することが多いのですが、頻繁にデプロイする環境だと 1 年で数百を超えるタスク定義が作られます。直近の数世代はロールバックする可能性があるので残しておきたいのですが、さすがに数か月前のリビジョンに戻すことはないため不要なものは断捨離したいと思っていました。 そういうリクエストが多かったのか、以前はタスク定義を非アクティブにすることしかできませんでしたが、今年の 2 月についに削除できるようになりました。 Amazon ECS が非アクティブなタスク定義リビジョンの削除をサポート さらに AWS が管理する Containers Roadmap のプロジェクトを眺めてみると、Issue #1967 でタスク定義にライフサイクルを追加してほしいというリクエストが挙がっていました(この Issue を作ったのは中の人っぽいので

                                                                          Amazon ECS の古いタスク定義を断捨離する "tdtidy" という隙間家具 OSS を作った | はったりエンジニアの備忘録
                                                                        • Amazon ECS increases applications resiliency to unpredictable load spikes

                                                                          Today, Amazon Elastic Container Service (Amazon ECS) enhanced tasks scheduling to make customers’ applications even more resilient to unpredictable load spikes. Now, Amazon ECS will first start a healthy replacement for each unhealthy task, that failed to pass a container or load balancer health check, before terminating it. This enhancement increases the resilience of customers’ applications with

                                                                            Amazon ECS increases applications resiliency to unpredictable load spikes
                                                                          • ECS(Fargate)からTiDB Cloud(Serverless)にPrivateLink経由で接続してみた | DevelopersIO

                                                                            こんにちは、ゲームソリューション部のsoraです。 今回は、ECS(Fargate)からTiDB Cloud(Serverless)にPrivateLink経由で接続してみたことについて書いていきます。 構成 プライベートサブネットにあるECS(Fargate)からPrivateLinkを経由して、TiDB Cloudのクラスターへ接続する構成です。 TiDB管理側の環境やVPCを明示的に記載していますが、ユーザー側で意識する必要はありません。 TiDB Cloudとは何か、TiDB Cloudのアカウント作成手順の説明は割愛します。 詳細については、以下記事をご参照ください。 TiDB Cloudでの準備 クラスタの作成 TiDB Cloudにてクラスタを作成します。 Tierは無料枠があるServerlessを利用し、リージョンは東京(ap-northeast-1)を選択します。 クラ

                                                                              ECS(Fargate)からTiDB Cloud(Serverless)にPrivateLink経由で接続してみた | DevelopersIO
                                                                            • 【永久保存版】0からAWSを勉強するならこのロードマップに従え! - Qiita

                                                                              はじめに こんにちは!!@Sicut_studyです! 先日出しました記事が多くの方に見ていだきました! 今回はAWSのロードマップの紹介です。 AWSを勉強しようとしている人からよく聞くのが AWS勉強したいけど何からしたらよいかわからないから資格の勉強しています 資格を勉強するのもいいですが最速でAWSを実践的に使えるということを目的にするなら、その方法は個人的には微妙かなと思います。 私もこのロードマップを行ったあとに試しに資格をとってみましたが、あまり実務に速攻的に役立つという感じではありませんでした (高度なものなら違うかもしれません) 私も2年前はAWSについてまったく知りませんでした しかし、とあるタイミングで 先輩がやっているようなAWSの環境を作って管理するのを私もできるようにならないと高みにいくことはできない このように思うようになり、ロードマップに沿ってに1から学習を

                                                                                【永久保存版】0からAWSを勉強するならこのロードマップに従え! - Qiita
                                                                              • 今更ながらFluent Bitって何だ!?となったので調べてみた話

                                                                                こんにちは、Яeiです。 今回は現役エンジニアである私がFluent Bitって何だという話についてまとめたいと思います。 最近巷で良く聞くFluent Bitと呼ばれるものがありますが、そもそもこれって何なのか調査しましたのでシェア致します。 最後はdocker-composeを用いたサンプルも用意しましたので見てみて下さい。 Fluent Bit 概要は公式サイトに分かりやすく書かれておりますので興味のある方は一読しておくとよいでしょう。 参考 fluentbitfluentbit また、各種ドキュメントは以下公式資料に詳しく書かれておりますのでこちらを参考にしてもらえればと思います。 参考 Fluent Bit ドキュメント 概要 Fluent Bitとは、 アプリケーションから出力されたログファイルや標準出力ログなどのデータを収集し、フィルタリングして複数の宛先に送信できるツールと

                                                                                  今更ながらFluent Bitって何だ!?となったので調べてみた話
                                                                                • インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ

                                                                                  こんにちは。カミナシでソフトウェアエンジニアをしているaomanです。 私のエンジニアとしての経歴はカミナシが2社目で、前職も含めフロントエンドからバックエンドまで一通り開発はしていました。ですが、AWSなどインフラに関しては、アプリケーション開発時必要になったところを少し触ったりするくらいで、ガッツリと本格的に学んだことがありませんでした。 そんな私ですが、今回ECS Clusterの切り替え作業を先輩エンジニア監修の元一緒に行う機会をいただきました。どのようなことをしたのか、簡単にではありますがご紹介させて頂こうと思います! ざっくり概要 カミナシのサービスでは、APIサーバーの運用にAmazon ECS(on Fargate)を利用しています。また、APIサーバーコンテナの他にいくつかのコンテナが起動しています。以下がざっくりとした図になります。1つのTask定義があり、4つのコンテ

                                                                                    インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ