「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億台”級
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
AWS Lambda（Python） の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO
作るもの ヒーローを管理する Lambda Function を書きます。ヒーロー情報は DynamoDB の ヒーローテーブルに格納するものとします。リポジトリは以下。 * Python Lambda SAM + SAM Local Project コーディング作業 すべてはコードを書くところから始めます。いきなりプロジェクトルートにファイルを置いて書き始めるのも良いですが、後々テストやデプロイも行うことになるので少し整理してみます。以下のようにしました。 . ├── buildspec.yml ├── deploy.sh ├── docker-compose.yml ├── environments │ ├── common.sh │ └── sam-local.json ├── integration_test.sh ├── requirements.txt ├── src
個人で運用している Web サービスをどう管理しているか 2018年版 - r7kamura - Medium
個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。 実験には Heroku を利用習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。 メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる（昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほど
なぜ AWS をやめて Heroku を選んだのか - sakagami memo
仕事であるアプリケーション開発を担っているのですが、 当初 AWS を用いて1人で運用していたのが、現在は Heroku のプラットフォームに移行し、チームとして6人で開発を行っている状況になりました。そこに至るまでの経緯とその際の運用についてご紹介したいと思います。 もちろんそれぞれの開発の状況に応じて、判断は変わってくるかと思いますが参考になればと思います。 エンジニア 1人 もともと私が関わる以前のそこでの開発は外注していました。運用を引き受けることになったのですが、 ある程度 形になっているアプリケーションを1人で運用するには不安が大きく、実装したい機能が日々 増えていく中で、インフラ面で時間をかけていて満足にコードを書けない状況は非常にわずらわしい ものでした。 小さなスタートアップという会社の中で、開発の施策が次々と進められない状況はまずい と感じ、Heroku の導入を検討し
AWSのオートスケールとなかよく付き合う
YAP(achimon)C::Asia Hachioji 2016 mid
Docker、そしてCloud FoundryとPaaSの価値とは
Docker、そしてCloud FoundryとPaaSの価値とは：James Watters氏に聞く（1/2 ページ） Docker人気を踏まえたとき、Cloud Foundryはどのように位置付けられるのか。PaaSの最終的な価値とは何なのか。AWSとの競合とは。Cloud Foundryの責任者である米PivotalのJames Watters氏に聞いた。 James Watters氏は、2010年9月から、Cloud Foundryに関わってきた。現在では米Pivotalのクラウドプラットフォーム事業担当バイスプレジデントとして、Cloud Foundry、Spring Source、Rabbit MQ、Redisを含む製品群の責任者を務めている。 この人の目には、「Dockerブーム」がどう映っているのか。また、Cloud Foundryはどのような点で差別化を続けていくのか。2
モンストを支えるインフラの今とこれから
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
AWS Solutions Architect ブログ
SA岩永です。クラウド時代になり、Blue/Greenデプロイと呼ばれる方式を取るシステムが増えてきました。ただ、日本語で書かれているBlue/Greenデプロイの情報は多少古いものが多いため、特にクラウドで真価を発揮するBlue/Greenデプロイについて2015年の最後に一度まとめてみたいと思います。 以下は私の個人的な考えに基づくものであり、他にも様々な考え方があります。AWSのデプロイに関する発表でも沢山の考え方が提案されていますし、デプロイをサポートするサービスを多種多様に提供しています。1つの考え方として参考にして頂ければ幸いです。 なおこの記事は、2015年のAWS re:Inventのセッション『(DVO401) Deep Dive into Blue/Green Deployments on AWS』を参考にしています。興味のある方はSlideshareやYoutubeを
Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
AWS News Blog
Top Announcements of the AWS Summit in New York, 2023 It’s probably no surprise that generative artificial intelligence and machine learning were the stars of the show, but there were several other bright lights from the day-long cloud conference. New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i) Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex
「Ansibleではじめるサーバ作業の自動化」を発表してきました
2014/10/11 に開催された PHPカンファレンス にて、「Ansibleではじめるサーバ作業の自動化」という発表を行ってきました。 午前中のセッションだったのですが、多くの方にご参加頂き、ありがとうございました。 発表資料 発表資料をslideshareに公開しました。 今回は、これからAnsibleを使ってみようという方を対象として、Ansibleの基本的な内容をメインにしました。また、実際に私自身がPHPプロジェクトで採用した際のユースケースを紹介しています。 発表後、「Ansibleをやってみます！」という意見を頂けたので、このセッションの目的は達成することができました:D このセッションのフィードバックは、joind.in にて受けて付けています。すでにいくつか好評価を頂いていて安心していますが、もし良かったらお願いします。 https://joind.in/talk/vi
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita
内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で
第288回 デプロイツール「Juju」を使って大魔導師を目指そう | gihyo.jp
やれ仮想化だ、やれクラウドだと、様々な単語が流行っていく中で、管理者が構築・運用しなければいけないサーバの数はどんどん増えています。今回はUbuntu Serverを「スケール」させるうえでとても便利なデプロイツールである「Juju」を紹介します。 Jujuとは 「Juju」はCanonicalが開発している「サービスオーケストレーションツール」です。公式サイトやホワイトペーパーでは抽象的な表現が多すぎて「お前は何を言っているんだ」状態なJujuですが、簡単に言うと「Amazon EC2やOpenStack、Azure、LXC、MAASといったサービス上にUbuntu Serverを用意し、そこに既存の各種サービスをデプロイするための自動化ツール」です。 Ubuntuにはもともと強力なパッケージ管理システムであるAPTが存在します。APTシステムを使えば多種多様なソフトウェアの依存関係の解
今さら聞けない Immutable Infrastructure - 昼メシ物語
Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クックパッドはなぜ開発しやすいのか // Speaker Deck
［速報］Dockerが分散アプリケーションのオーケストレーション機能を発表。Docker Machine、Docker Swarm、Docker Compose
Cookpad's deployment and auto scaling
