並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 198件

新着順 人気順

Fargateの検索結果1 - 40 件 / 198件

  • 「1億台の常時接続」を実現せよ! Nintendo Switchのプッシュ通知システム全面刷新の裏側 (1/3)

    アマゾン ウェブ サービス ジャパンは、2024年6月20日と21日、国内最大の年次イベントである「AWS Summit Japan」をハイブリッドで開催。150を超えるセッションが展開された。 本記事では、ニンテンドーシステムズによるセッション「Nintendo Switch向けプッシュ通知システムのリプレイス事例」をレポートする。登壇したのは、同社 システム開発部の林愛美氏と坂東聖博氏だ。 2017年のNintendo Switchの発売とあわせてリリースされた「プッシュ通知システム」。同社は、長期運用を見据えて、よりクラウドネイティブなシステムへのリプレイスを決定するが、大量のTCP接続を維持するための様々な課題が立ちふさがった。 本セッションでは、AWS FargateやNetwork Load Balancer(NLB)といったAWSのマネージドサービスを用いた、“最大1億台”級

      「1億台の常時接続」を実現せよ! Nintendo Switchのプッシュ通知システム全面刷新の裏側 (1/3)
    • 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
      • プライベートIPアドレスと同じ用途のIPv6アドレスが存在しない件について:Geekなぺーじ

        IPv4には、プライベートIPアドレスとして割り当てられたアドレスブロックがあります。 1996年に発行されたRFC 1918で規定されている10.0.0.0/8、172.16.0.0/12、192.168.0.0/16の3つです。 NAT(NAPT)とともにプライベートIPアドレスは、多くの環境で利用されています。 企業LANなどでIPv4ネットワークを構築するときに、プライベートIPアドレスを一切使わずにグローバル(パブリック)IPアドレスのみで組むようことは、いまでは少ないのではないかと推測しています。 世界中で多く利用されているIPv4のプライベートIPアドレスですが、2024年現在時点において、IPv4のプライベートIPアドレスと全く同じ用途のIPv6アドレスは存在しません。 IPv6には、ULA(Unique Local Address)というアドレスがあります。 「ULAって

        • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

          公開日 2024/05/28更新日 2024/12/02注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット会員限定コンテンツ無料登録してアーキテクチャ

            注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
          • 弊社の「意識チョット低いアーキテクチャ」10選

            「CTOの視点で選ぶ「最適な」アーキテクチャとは?」というイベントで登壇しました。 本記事は登壇資料をMarkdownとしてそのまま記事化したものです。スライドのほうが読みやすい方は、Speaker Deckで御覧ください! 自己紹介1|職歴、趣味など 職種・SNS 株式会社NoSchool CTO 2016年〜Webエンジニア。2019年〜現職 Twitter(X): 名人|マナリンクCTO Zenn: https://zenn.dev/meijin 好きなHTTPヘッダーはCache-Control 趣味 将棋☗、カメラ📸、ラム酒🥃、個人開発💻、筋トレ💪、高校野球観戦⚾ 自己紹介2|外部発信・諸活動 ZennでReact記事が人気 歴代記事でLike数1位(登壇時点) 個人開発 テストメーカー(ユーザー20,000人以上) エンジニア向け教材執筆 「LaravelでFat Co

              弊社の「意識チョット低いアーキテクチャ」10選
            • AWS ECS Fargate Autoscaling の実戦的な基礎知識 | 外道父の匠

              Autoscaling については過去に何度か書いているのですが、今回は ECS Fargate について少し掘り下げつつ整理してみたいと思います。 仕組みとしては難しくはなく、わりと雑な理解度でも動くっちゃ動くとはいえ、リソースとしての重要度は高い箇所であり、正しく理解するとより関連箇所の最適化が見込めるところでもあります。 概要 ECS は on EC2 で動かすと、インスタンスとタスクの二段階での Autoscaling になるところが、Fargate だとタスクのみで考えられる簡素さが強みです。 ECS Service のタスク群に対して、特定の条件(主に平均CPU使用率)を満たした時にタスク数を自動的に増減することで、負荷対策とコスト削減という目的を達成しつつ、運用者が基本は放置できることになります。 ただ、それだけの理解では浅すぎるので、増減における詳細やリスクなどについて把握

                AWS ECS Fargate Autoscaling の実戦的な基礎知識 | 外道父の匠
              • 今あらためてコンテナ界隈を俯瞰する「Docker/Kubernetes コンテナ開発入門」 | DevelopersIO

                単著ならではの一貫性と、筆者のノウハウをありったけ突っ込んでやろう!というあっつい想いを感じる素晴らしい書籍です。 「2018年から2024年、コンテナ界隈もいろいろ変わったもんだなぁ…(しみじみ)」 献本いただいた「Docker/Kubernetes 実践コンテナ開発入門 改訂新版」を眺めながら、ハマコーはそんな感慨にふけっておりました。 5年前、Docker始める人はまずこれ!書評「Docker/Kubernetes 実践コンテナ開発入門」で旧版の書評を書いたご縁で、著者の山田さんより改訂新版の献本をいただき、今この場にその本があるというわけです。 改めて中身読んでいたのですが、単著でこれはマジでやばいです。今コンテナを使った開発を進めようとしたときにでてくるであろう、開発〜運用面でのトピックが幅広く凝縮されている本で、「これ一冊読んどけば、マジはずれないよ」というぐらいの力が入った書

                  今あらためてコンテナ界隈を俯瞰する「Docker/Kubernetes コンテナ開発入門」 | DevelopersIO
                • MySQLのロックに起因するブロックタイムアウト撃退記 - inSmartBank

                  こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし

                    MySQLのロックに起因するブロックタイムアウト撃退記 - inSmartBank
                  • AWS Lambdaを支える技術 - ABEJA Tech Blog

                    こんにちは、今年の4月に新卒入社でABEJAに入社しました島倉と申します。 現在はプロジェクトマネージャーとして働いています。 これはABEJAアドベントカレンダー2024の9日目の記事です。 なぜFirecrackerが開発されたのか 従来の仮想化技術の課題 Firecrackerの設計要件 Firecrackerとは何か Firecrackerのアーキテクチャ Firecrackerのコード解説とその仕組み microVMの仕組み MicroVMはなぜ軽量なのか 1. 起動プロセスでカーネルを直接ロード 2. mmap による効率的なメモリ管理 3. KVMを利用したvCPU管理 4. Seccompで不要なシステムコールを制限 5. 最小限のVirtIOデバイス まとめ We Are Hiring! 今回は、生成AIの発展が注目されている中あえて、「地味だけど重要な技術」にフォーカス

                      AWS Lambdaを支える技術 - ABEJA Tech Blog
                    • アンチウイルスソフト Antivirus for Amazon S3 を本番環境に導入してみてわかったメリット・デメリット - ANDPAD Tech Blog

                      こんにちは。SREチームの吉澤です。 アンドパッドでは最近、AWSのS3バケット上のファイルをスキャンするために、アンチウイルスソフト Antivirus for Amazon S3 を本番環境に導入しました。その結果、私たちの要件はほぼ全て満たされたうえに、従来比で大幅なコスト削減を実現できました。 Antivirus for Amazon S3について日本語で書かれた記事はまだ少ないですが、S3に対するウイルススキャンが求められるケースでは、導入を検討する価値があるソフトです。 そこで、今回はこのAntivirus for Amazon S3の概要、私たちが本番環境に導入してみてわかったメリットやデメリット、そしてこのソフトが適した状況をご紹介します。 背景 S3に対するウイルススキャンが必要な理由 Antivirus for Amazon S3の導入前に利用していたソフト Antiv

                        アンチウイルスソフト Antivirus for Amazon S3 を本番環境に導入してみてわかったメリット・デメリット - ANDPAD Tech Blog
                      • AWS ECS Service のオススメ監視項目 | 外道父の匠

                        前記事 AWS ECS Fargate Autoscaling の実戦的な基礎知識 の続きというか派生的なところで、こんな監視項目がこんな理由でえぇんちゃうん、という基礎知識的なお話です。 当ブログでは『監視よければ全てヨシ!』という格言を推していますので、監視の仕込みをサボっている人は今からでも頑張っていきましょう。 はじめに もともと書くつもりでいた本タイトルは、公式からこのドキュメントが出たことで、ゴミ箱行きかと思いました。 推奨アラーム – Amazon CloudWatch > Amazon ECS んが、まぁ所詮はドキュメントということで、ここではもう少し実戦に寄り添う形でまとめていければと思います。 あったら嬉しい監視項目をカテゴリごとに整理しつつ、その理由やら補足情報によって、楽しく監視できるようにしていきたいところです。合わせて読みたいところとしては、この辺もどうぞ。 ミ

                          AWS ECS Service のオススメ監視項目 | 外道父の匠
                        • 【AWS】障害時の調査事項まとめ ~ELB・ECS・RDS~ - Qiita

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

                            【AWS】障害時の調査事項まとめ ~ELB・ECS・RDS~ - Qiita
                          • プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術

                            プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術 2024年3月5日 株式会社サイバーエージェント インフラエンジニア 青山真也 (Masaya Aoyama) 2016年、新卒でサイバーエージェントに入社。OpenStackを使ったプライベートクラウドやGKE互換なコンテナプラットフォームをゼロから構築し、国内カンファレンスでのKeynoteに登壇。著書に『Kubernetes完全ガイド』『Kubernetesの知識地図』『みんなのDocker/Kubernetes』。現在はKubernetesやOpenStackなどOSSへのコントリビュート活動をはじめ、CloudNative Days Tokyo Co-chair、CNCF Japan ChapterのOrganizer、Kubernetes Meetup TokyoのOrgani

                              プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術
                            • 大規模システムを知るために、まず監視を学んだ話 - NRIネットコムBlog

                              本記事は ブログ書き初めウィーク 2日目の記事です。 📝 1日目 ▶▶ 本記事 ▶▶ 3日目 📅 こんにちは、NTシステム事業二部 基盤課 の玉邑です。 2024年7月にNRIネットコムに入社し、AWS上に構築された大規模システムのインフラチームリーダーを担当しています。お客様のビジネスの変化に迅速に対応するため、DevOpsで開発を行いながら、安定稼働を支えるSREを担当しています。 15年以上にわたりインフラエンジニアやクラウドアーキテクトとしてキャリアを積んできましたが、現在担当しているシステムはこれまでで最も規模が大きいものです。今回の記事では、入社してからどのようにしてその大規模システムを理解し、リーダーとして業務をキャッチアップしていったかについてお話ししたいと思います。 担当したシステムについて 監視を通じて知る大規模システム システムの全体像を知ることができる システム

                                大規模システムを知るために、まず監視を学んだ話 - NRIネットコムBlog
                              • 日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表

                                日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル:2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi

                                  日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
                                • 令和に構築するEC2踏み台サーバー - y-ohgi's blog

                                  TL;DR 令和に踏み台サーバーを作成する Amazon Linux 2023AMIとSSM Agentを利用したEC2 証跡を取得する About EC2とSSMのセッションロギングを使用して証跡を取得することが目的。 ECS/Fargateでも同様のことが可能ですが、SSM AgentがプリインストールされているAMIのEC2を使い捨てる方が運用コスト的や構築コスト的に楽なためEC2を選択。 How To アーキテクチャ Instance Profileの作成 assumerole.json $ cat <<EOL > assumerole.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action

                                    令和に構築するEC2踏み台サーバー - y-ohgi's blog
                                  • Kubernetesを知る

                                    2024/12/2 ゼミでの発表に使った資料です。

                                      Kubernetesを知る
                                    • 衛星管制システムとは何か - ArkEdge Space Blog

                                      コンピューティング基盤部の三吉(sankichi92)です。 先月12月にアークエッジ・スペースの開発した衛星「AE1b」が国際宇宙ステーションから放出され、さらに、1月15日には「AE1c」と「AE1d」が打ち上げられ、これらの衛星の運用がはじまりました。 アークエッジ・スペースでは、衛星を効率的に運用するための管制システム1を自社で開発しています。 この記事では、非宇宙分野のソフトウェアエンジニア、特に Web 系エンジニアを対象に、衛星管制とは何か、また、衛星管制システムがどのようなものかを紹介します。 衛星管制とは 衛星管制における通信の制約 衛星管制システムの機能 テレメトリ・コマンド処理 地上局ハードウェアの抽象化 パス予測とコンタクト予約管理 衛星やコンタクトのメタデータ管理 衛星管制システムの技術スタック 衛星運用の今後の展望 衛星管制とは 宇宙開発というとロケットのイメー

                                        衛星管制システムとは何か - ArkEdge Space Blog
                                      • 身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools

                                        多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社会員限定コンテンツ無料登録してアーキテクチャを見る アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー!」やD2C型SaaS「ウラカタ」を始め、1,000万会員/1万施設を超える顧客に複数サービスを提供しています。

                                          身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
                                        • 39社のデータアーキテクチャ特集 - ツールの技術選定のポイントと活用術 - Findy Tools

                                          8つのデータ系ツール「BigQuery」「Databricks」「dbt」「Fivetran」「Lightdash」「Looker」「Snowflake」「TROCCOⓇ」に39社からご寄稿頂いたレビューから、各社のデータアーキテクチャをまとめた記事です。各社の技術選定の背景や工夫などの知見を得ていただく場となれば幸いです。 ※ツール名・ご寄稿企業名共にアルファベット順で掲載しております BigQueryBigQuery は、Google Cloud の費用対効果に優れたフルマネージド型の分析データ ウェアハウスです。ペタバイト規模に対応しており、膨大な量のデータに対してほぼリアルタイムで分析を行うことができます。 ▼BigQueryとは?機能や特徴・製品の概要まとめページはこちら https://findy-tools.io/products/bigquery/49 ▼Findy Too

                                            39社のデータアーキテクチャ特集 - ツールの技術選定のポイントと活用術 - Findy Tools
                                          • awslim - Goで実装された高速なAWS CLIの代替品を作った - 酒日記 はてな支店

                                            最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio

                                              awslim - Goで実装された高速なAWS CLIの代替品を作った - 酒日記 はてな支店
                                            • 円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ

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

                                                円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ
                                              • ECSのIaCあるある『Serviceとタスクの更新をどこでやる問題』に向き合う一例 - Nealle Developer's Blog

                                                お疲れ様です。今年は豪雪らしくワクワクが止まらないスノーボーダーの2357giです。 AWSリソースをIaCで管理しているプロジェクトにおいて、IaCリポジトリとアプリケーションリポジトリが分かれている中で、どのようにアプリケーション用ECS ServiceのCDを実現するかは悩むところではあると思います。 そんな中で、弊社がどのような構成でそれを実現しているかを紹介したいと思います。 特筆して珍しいことは行なっていないのですが、AWSリソースをIaC化し始めた方の参考になれば幸いです🙌 背景 ALBとECS Service自体はインフラリソースであり、IaCリポジトリで管理したいという思惑があります。 それに対して、ECS ServiceやECSタスク定義のライフサイクルはアプリケーションと一致しており、アプリケーションリポジトリから更新したいです。ここでいうライフサイクルの一致とは、

                                                  ECSのIaCあるある『Serviceとタスクの更新をどこでやる問題』に向き合う一例 - Nealle Developer's Blog
                                                • 大規模サービスのインフラを全面的にリプレイスした話 - Qiita

                                                  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは。雑食系エンジニアの勝又です。 今回は、私が2年ほど参画させていただいた大規模サービスのインフラやDevOps周りを全面的にリプレイスしたお話について簡単にご紹介させていただきます。(内容に関しては事前に参画先企業様に確認していただいております) サービス概要 詳細な内容は伏せますが、メインとなるテーブルのレコード数が数十億件、スパイク時には数万〜数十万のユーザーが一斉にアクセスする大規模サービスです。 技術的負債 長く運用されてきたサービスのあるあるですが、新機能の追加が最優先されてきたことにより、こちらのサービス

                                                    大規模サービスのインフラを全面的にリプレイスした話 - Qiita
                                                  • AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう | Amazon Web Services

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

                                                      AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう | Amazon Web Services
                                                    • 話題のLLMローコード構築ツールDifyをAWSのマネージドサービスで構築してみた - エムスリーテックブログ

                                                      こんにちは。エムスリーエンジニアリンググループのコンシューマチームに所属している園田です。 普段の業務では AWS やサーバーサイド、フロントエンドで遊んでいるのですが、最近はもっぱら OpenAI や Claude3 で遊んでます。 今回は、最近巷で話題の LLM ローコード構築ツールである Dify の OSS 版を AWS のマネージドサービスのみを使って構築してみました。 DifyとはオープンソースのLLMアプリ開発プラットフォームで、様々なLLMを使用してChatGPTのGPTsのようなものがノーコードで簡単に作れます。 引用元: DifyでSEO記事作成を試してみる|掛谷知秀 試しにAskDoctorsのガイドラインHTMLをナレッジ登録してみた ローカル環境で Dify を構築する記事はたくさん見かけますが、AWS のマネージドサービスで構築する内容は見かけなかった*1ので公

                                                        話題のLLMローコード構築ツールDifyをAWSのマネージドサービスで構築してみた - エムスリーテックブログ
                                                      • hadolintを使ってDockerfileをベストプラクティスに沿った状態に保つ

                                                        Dockerは公式にDockerfileのベストプラクティスを表明しています。 が、このベストプラクティスに沿っているかどうか?を人間がいちいちレビューしていくのは正直しんどい、というか現実的ではない… そこで「せや!静的解析したろ!」という時に便利なのがhadolintというライブラリです。 使ってみる 今回はVSCode拡張機能とGHAのCI時に静的解析してもらいたいと思います。 今回はちょうどメンテナンスしていない自分のリポジトリがあるので、これに対して静的解析をかけていきます。 まずはVSCode拡張機能で利用するための下準備として、hadolint本体をOSにインストールします。 Macの場合はこちら。 docker/php/Dockerfile:8 DL3008 warning: Pin versions in apt get install. Instead of `apt-

                                                          hadolintを使ってDockerfileをベストプラクティスに沿った状態に保つ
                                                        • AWSLogs コンテナログドライバーのノンブロッキングモードによるログ損失の防止 | Amazon Web Services

                                                          Amazon Web Services ブログ AWSLogs コンテナログドライバーのノンブロッキングモードによるログ損失の防止 この記事は Preventing log loss with non-blocking mode in the AWSLogs container log driver (記事公開日: 2023 年 8 月 3 日) を翻訳したものです。 Introduction 可観測性の向上とトラブルシューティングのために、コンテナログをコンピューティングプラットフォームから、ログ集約サーバーに転送することをお勧めします。実際には、ログサーバーが到達不能になったり、ログを受け入れられなくなる場合があります。ログサーバーの障害に対するアーキテクチャ設計には、トレードオフがあります。サービス所有者は、次の点を検討する必要があります。 アプリケーションは、トラフィックへの応答

                                                            AWSLogs コンテナログドライバーのノンブロッキングモードによるログ損失の防止 | Amazon Web Services
                                                          • Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate

                                                            Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate

                                                              Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate
                                                            • モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

                                                              ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております 株式会社あしたのチーム会員限定コンテンツ無料登録してアーキテクチャを見る あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス:パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。 アーキテクチャ選択の背景や意図 サービス立ち上げ初期はエンジニアの数が少ないこともあり、開発メンバーが開発と兼任でイ

                                                                モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
                                                              • 自社データ × ChatGPTで社内AIを構築するRAG ツール|Doox β版をリリースしました - Qiita

                                                                TLDR 社内のデータを元に質問への回答を LLM が生成する仕組み(RAG)を構築するためのサービスを開発しました。 β 版として無料で公開しているので是非使ってみてください。 サーバーレスな構成で Next.js を動かしている。技術のキャッチアップは大変だ。 背景 仕事をしていると社内の規定 / 製品情報 / 過去の履歴 .. などに関する問い合わせは日常的に発生するものだし、その工数は結構ある。通常は Wiki を作ってナレッジを共有するが、結局「近い人や担当に聞く」という行為はなかなか減らない。 色々な企業が、社内のデータを元に質問への回答を LLM が生成する仕組み(RAG)を独自に開発しているようで、技術ブログとかに書いている方も多い。 社内向け RAG の構築を SaaS プロダクトで提供したら各社の社内の問い合わせ工数と独自に RAG を構築するコストを下げられて嬉しいん

                                                                  自社データ × ChatGPTで社内AIを構築するRAG ツール|Doox β版をリリースしました - Qiita
                                                                • AWS RDS Proxy の実戦的な基礎知識 | 外道父の匠

                                                                  RDS Proxy はリリースして4年以上経過(Amazon RDS Proxy が一般提供開始)しましたが、そこまで一般的な情報は多くないのと、自分の整理の意味を込めて適度に吐き出しておきたいと思います。 用途はいくつかある中で、今回は単純な負荷に対するスケーリング対策としての内容となります。今年最後の記事なのに想像込みの部分もあって絞まらないかもですが、お手柔らかにお願いします。 はじめに RDS Proxy は便利な可能性を提供してくれるものですが、ただ導入しただけで幸せになれる類のものではありません。どのような仕組みであり、なぜ効率が良くなり、どのように扱えばよいのか、について正しく理解しようとする姿勢が必要なのは、他のシステムと同じです。 基本的な情報についてはリンクを置いておきますので、そちらに任せるとして、ここではそういう情報を一見しただけではわからなそーな部分についてまとめ

                                                                    AWS RDS Proxy の実戦的な基礎知識 | 外道父の匠
                                                                  • Fluent Bit の低レイヤーに飛び込んでみて、わかったこと

                                                                    こんにちは! シェルフィー株式会社で SRE を担当している石田です。 弊社では、本番のワークロードにて Fluent Bit を使っております。 今回、Fluent Bitの処理について理解を深めたので記事を書いてみました。 世界中で使われているとても有名なミドルウェアなので、参考になればとても嬉しいです。 はじめに 弊社では、ECS on Fargate で稼働しているバッチジョブのログをサイドカーコンテナ(Fluent Bit)を使い Datadog に連携しています。 ログのサイズが 16 KB 以上ある場合、shim-logger の仕様により、そのログは分割されてしまうため、 Fluent Bitにて分割されたログの再結合処理を行う必要性があります。 この点についてはDeNAさんの記事がわかりやすいので、詳細はそちらを参考にしてもらえたらと思います。 AWS ECS on Fa

                                                                      Fluent Bit の低レイヤーに飛び込んでみて、わかったこと
                                                                    • 【個人開発】爆速な賃貸検索サービスをさらに高速化した【Rust】 - Qiita

                                                                      Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 個人で運営している賃貸物件の検索サービス Comfy のバックエンドを Rust でリプレースしました。この記事では、そのリプレースの背景と詳細をご紹介します。 まずは結果から 技術構成: Rust + Cloud Run1 へ移行 (Python + GCE2 から) 性能向上: 約 1.5 倍 開発期間: 1 ヶ月間 コード行数: 約 40 % インフラ費用: かなり減少 (多分3) 短い期間・少ないコードでかなり高速化できちゃった上に、開発体験もとてもよい Rust は本当に素晴らしいです…!! サービス概要 Comfy は 日本

                                                                        【個人開発】爆速な賃貸検索サービスをさらに高速化した【Rust】 - Qiita
                                                                      • 【30歳/完全未経験/独学】webアプリを作製しました【Golang, Next.js, MySQL, Docker, GitHub Actions CI, AWS Fargate on ECS】 - Qiita

                                                                        完成物 ER図 画面遷移図 figma, 原寸画像 AWS構成図 ※備考※ GitHub Actions CIは構築済みです。 GitHub Actions CD, apiのprivate subnet化にも取り組んでいます。 EC2インタンスは通常時停止です。 技術選定理由 プログラミング、IT業界ともに未経験で着手し独学で作りました。 Go 比較対象:JAVA、Ruby、Python、PHP コンパイラ言語であり実行速度が高速である 静的型付けであり、コンパイル前にバグを発見しやすい 静的型付けかつ記述自由度が低いことから、以下2点を利点と考えた 開発を中長期まで続けた際にも、加筆・改修しやすい 他人のコードを読んだ際に学びやすい Javaも多少書いてみたが、簡素にかけるGoの方がしっくりきた SHOWROOM、IRIAM、Twitch、AbemaTVといった動画配信サービスにも採用さ

                                                                          【30歳/完全未経験/独学】webアプリを作製しました【Golang, Next.js, MySQL, Docker, GitHub Actions CI, AWS Fargate on ECS】 - Qiita
                                                                        • なぜCloudflareを選択?12社の選定背景・活用のリアル - Findy Tools

                                                                          公開日 2024/11/29更新日 2024/11/29なぜCloudflareを選択?12社の選定背景・活用のリアル CDNやストレージをはじめ、Cloudflare社のプロダクトには多様な機能があります。 本記事の前半部分では、Cloudflare Japan エバンジェリストの亀田治伸さんに、改めて「Cloudflareとは何か?」「どんな機能があり、それぞれの特徴・メリットは?」をテーマにご解説頂きます。 後半部分では、「各社が実際にどのようにCloudflareを活用しているのか? 」に焦点を当て、Findy Toolsにご寄稿頂いたCloudflareレビュー記事から事例をご紹介していきます。 ※各社の事例はレビュー公開時点の情報になります 【Cloudflare Japan 亀田氏 解説】Cloudflareとは?Cloudflare(クラウドフレア)は、インターネットのパフ

                                                                            なぜCloudflareを選択?12社の選定背景・活用のリアル - Findy Tools
                                                                          • [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
                                                                            • ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products

                                                                              3年ほど前に登場した比較的新しいサービスであるApp Runnerを商用環境で導入した事例を紹介します。 インフラの運用の手間を軽量化できる一方で、利用して初めて気づく課題もありました。 本日は実際の導入事例に基づいて、ECS Fargateとの比較、CI/CD・監視の工夫から障害発生時の運用方法と…

                                                                                ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products
                                                                              • "Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想

                                                                                AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。 一般的な感想 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた HTTP/2 を利用した独自プロトコルでの双方向通信が気になる TCP/IP を利用した大量の常時接続は本当に大変だとおもう カーネルパラメーターチューニング! 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい デプロイの自動化を GitHub Actions でやってるのやっぱりいい 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高 Graviton ベースの Fargate の活用 Go であれば arm64 向けバイナリがサクッと生成されるのは良い Erlang/OTP から Go へ

                                                                                  "Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想
                                                                                • 大規模サービスのローンチに向け、パフォーマンスチューニングした話 #go #aws

                                                                                  背景 こんにちは!Hanoi Dev Centerでバックエンドエンジニアをしているminhquangです。この記事では、私がAI事業本部のある新規プロダクト開発に参画した際に経験したパフォーマンスチューニングについて話したいと思います。 皆さんはサービスのローンチ(サービスを世の中に初めて出すリリース)をやったことがありますか。サービスローンチするときに、リクエストのスパイクや、ユーザー数の増加によるサーバー負荷増加など、様々な未知な課題が存在します。 私のチームでは数百万人の利用が見込まれるサービスにおいて、18000RPSを実現するべく負荷試験とパフォーマンスチューニングを実施しました。 本記事では、上記のサービス要件を満たすために私たちが取り組んだ負荷試験やパフォーマンスチューニングについて説明しつつ、これらの経験から得られた学びを共有したいと思います。 前提 技術スタック サーバ

                                                                                    大規模サービスのローンチに向け、パフォーマンスチューニングした話 #go #aws