10倍に膨れたAWS運用費をどう減らす？ ユーザー急増のnoteが挑む「コスト削減作戦」の裏側
10倍に膨れたAWS運用費をどう減らす？ ユーザー急増のnoteが挑む「コスト削減作戦」の裏側（1/2 ページ） 文章やイラストなどを投稿できるコンテンツ配信サービス「note」。コロナ禍以降は巣ごもり需要にも後押しされてユーザー数が急増しており、2020年には月間アクティブユーザー数が前年同期比で3倍以上に増えたという。しかし同時にトラフィック量も急増したため、運営元であるnote社のシステム部門ではその対応に追われた。特にクラウドサービスの利用コストの高騰は、大きな悩みの種だった。 noteのサービスを支えるシステムは、全てAWS（Amazon Web Services）のクラウドインフラ上で構築・運用しており、トラフィック急増でその利用コストは約10倍にまで膨れ上がった。 このままトラフィックがさらに増えれば、コストが利益を食いつぶすことにもなりかねない。そこでシステムの運用や品質管
プロトタイプ汚染周りの提案と primordials.js
はじめに この記事では TC39 のプロトタイプ汚染周りの提案、そしてグローバルやプロトタイプのプロパティ変更に耐えるためのコードである primordials.js について紹介します。 プロトタイプ汚染とは JavaScript はプロトタイプベースの言語です。どのオブジェクトもプロトタイプ（[[Prototype]] 内部スロット）を持っており、それを辿ることで継承を表現します（プロトタイプチェーン）。 JavaScript では基本的にどのオブジェクトも凍結されておらず、好きにプロパティを追加していくことができます。かつて Prototype JavaScript Framework や MooTools というライブラリが広く使われ、ビルトインオブジェクトのプロトタイプに独自のメソッドを追加して Web サイトを開発していました。しかしオブジェクトが直接所有するプロパティとプロト
ISUCON11本選のしくじりを振り返っていく - Mirrativ Tech Blog
こんにちは、バックエンドエンジニアのmakinoです。ISUCON11本選から1ヶ月半が経過し、2年連続失格の傷が癒えてきたので振り返りブログを書いていこうと思います。 ISUCON11本選について 本選の題材は大学の履修登録サイトでした。 すでに作問陣による本選問題の解説と講評が出ているので、問題の詳細については下記の記事をご参照ください。 isucon.net 今回の問題は、高負荷な箇所を改善してもスコアが一気に上がるようなことはなく、じわじわ伸びていくような問題だったので競技時間中はずっと苦しんでいました。 また、本選出場30チーム中12チームが失格になったことからも、問題の難易度が窺えるかと思います。 弊チーム「カレーおじさん」の最終スコアは68,347点でしたが、最後の負荷走行にてfailになってしまい失格となってしまいました。 また、運営の方が競技終了後に一時的にサーバーを開放
Google ColabとVSCodeで作るデータ分析環境 クラウドのGPU環境でもローカルと遜色ない開発体験を
「分析コンペLT会」は、KaggleやSIGNATEなど、データ分析のコンペに関連するLT（ライトニングトーク）を行う会です。野澤氏は、Google Colabとvscodeを用いて作るデータ分析環境とその運用について発表しました。 機械学習の勉強環境の1つ「Google Colaboratory」 野澤哲照氏（以下、野澤）：「Google ColabとVSCodeを用いたデータ分析環境運用Tips」ということで、野澤が発表します。 最初から免責で申し訳ないのですが、今日紹介する方法はGoogle側が推奨している方法ではないので、急に使えなくなる可能性もあります。そこだけご了承ください。 今日話す内容ですが、ざっくりGoogle Colab（Google Colaboratory）とVSCodeを紹介して、最終的にどういう環境が作れるかというところと、環境構築手順・運用時のポイントなどを話
AWS アカウントを横断して SSH ポート全開放を検知・修復する仕組みを導入した話 | BLOG - DeNA Engineering
はじめに こんにちは、IT 基盤部ネットワークグループの尾留川です。 普段は、DeNA グループ全体のネットワークの管理、運用等を行っています。 今回は、社内全ての AWS アカウントのセキュリティグループにおいて、 SSH(TCP/22) ポートの全開放を検知し、ルールの自動削除を行うような仕組みを導入したので、ご紹介します。 導入の背景 社内で利用している AWS アカウントの総数は約 300 程度あり、これらのアカウントで SSH ポートの全開放を人の手で検知、対応することは困難でした。 元々、社内では Public IP を持つインスタンスに対して、一定時間毎にインターネット経由で SSH を試行し、SSH ポートが外部に開放されていないかを検知する仕組みが存在していましたが、以下のような問題点がありました。 インスタンスの数が膨大なため、 SSH の試行に時間を要する 開放検知後
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
