30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
ヤフーの画像配信システム（CDN）の紹介
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括本部プラットフォーム開発本部の新部（@osa2be）です。 CDNの運用を担当しています。 先日、知り合いの技術者と話していてヤフーのバックエンドがどうなっているのか興味があると聞かれましたので、社内にいくつかあるCDNのうち2つとIDCフロンティアのサービスをご紹介します。 はじめに ヤフーには多くのサービスが存在していますが、様々な理由により突発的にリクエストが増加することがあります。 そのようなリクエストに対応するためにサービスごとに大きな配信システムを持つことは、インフラの準備や運用工数など高いコストが必要になります。 そのため、共通のCDNを準備して各サービスのサーバ負荷を平滑化しています。 以前は、社外のC
料理を楽しくする画像配信システム
The document describes TOFU (Tofu on the Fly), a system for dynamically generating and caching image thumbnails on Amazon S3. It works by installing an Apache module that generates thumbnails using ImageMagick when images are requested, then caches them on S3 for future requests. This avoids hitting application servers for every image and provides scalability. The document discusses the TOFU archi
私がクックパッドの画像配信野郎です - 昼メシ物語
一年ほど前にヤフーを退職した私ですが、その後なにをやっているかというと、クックパッドに入社して画像配信をしています。私が入社する前から動いていた画像配信の仕組みは設計が古くてなにかと困っていたので、より良いシステムを開発してリプレースというのをやっています。前職ではなかなかこういう基盤システムを一人でイチから作って運用までするという体験はできなかったので、でかい仕事をできるチャンスに恵まれて大変充実した毎日です。 入社当初はサービス開発の担当だったんですが、開発に必要な基盤システムを作り始めたらどんどんエンジニアリングのレイヤーが下がってきて、気づけばインフラチームに所属していました。 まあそんな話はさておき、この画像配信関連の成果をいくつかの勉強会で発表したので、その資料を紹介します。 サイバーエージェントxクックパッド合同勉強会（amepad） 弊社オフィスで開催された、サイバーエージ
ImageFluxを利用した画像配信の最適化〜動的リサイズとWebP変換〜 | メルカリエンジニアリング
SREチームの@cubicdaiyaです。今回はメルカリにおける画像配信とImageFluxを利用した画像の動的なリサイズとWebP変換の導入によってアプリのデータ通信量を大幅に削減した事例について紹介します。 ImageFluxはクラウド画像変換サービスです。URLに画像変換用のパラメータを組み込むことで画像データの拡大・縮小やオーバレイ、フォーマット変換等が実現できます。 メルカリにおける画像データ メルカリのアプリ上で発生するデータ通信の大部分はタイムラインや検索結果に表示される画像データが占めています。種類はいろいろありますが例えば、 商品画像 プロフィール画像 バナー画像 といったものが挙げられます。特に商品画像はデータ量がとにかく多く、毎日百万個単位で増加するほか、タイムラインや検索結果をはじめ、多くの機能で活用されています。 ImageFluxを利用した画像変換でデータの通信
開発部・システム運用グループの長野です。最近は「サーバ／インフラを支える技術」を読みながら通勤しています。今回はmixiの画像配信について書かせて頂きたいと思います。1回目は画像配信の課題について説明させて頂きます。 ■画像配信の種類 これまで画像の配信は大きく分けて2種類あると考え、システムを構築してきました。1つは１ファイルあたりへのアクセスが非常に多くなりますが、ファイル数が少ないもの。もう一つはファイル数が膨大になる代わりに、１つのファイルへのアクセスは少ないものになります。 前者はmixiの中で使われるロゴ画像やメニューの画像等のページ部品、また広告画像や絵文字画像になり、後者はユーザがアップロードする日記やアルバムの画像にあたります。ページの部品の画像はファイル数はそれほど多くないものの、サーバへのアクセス数が最大で秒間に数万リクエストにもなります。逆にアルバムや日記の画像は全
Togetterを支えるお手軽画像配信サーバ（1）Camoで実現するセキュアな画像プロキシサーバ - Qiita
こんにちは。トゥギャッター株式会社でバックエンド中心にエンジニアをしている @MintoAoyama です。 Togetter はツイートを始めとした様々な情報を組み合わせてコンテンツを作り出すキュレーションサービスです。 2009年に誕生してから今年で8年目に突入し、現在も月間6000万PV・1200万UUを超える規模で成長を続けています。 海外版の Chirpstory も政治家・公共団体・ジャーナリストなど影響力のあるユーザに支えられ、成長を続けています。 そんなTogetter・Chirpstoryを支えるシステムの1つに 画像配信サーバ があります。もう少し詳しくすると リアルタイム変換機能付き 画像プロキシサーバ です。 この仕組み、特に当サービスにおいては地味に重要な役割を持っているのですが、社内に関心を持って貰える人が居なかった（※）ので、とりあえずここに整理することにしま
http://d.hatena.ne.jp/yamaz/20060509の続き. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる. GoogleがこんなことができてるのはGoogleFileSystemがあるからだ. http://labs.google.com/papers/gfs.html GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ. GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
YAPC::Asia 2009で大規模画像配信とPerlについて発表しました - mixi engineer blog
開発部・システム運用グループの長野です。9月10日・11日に東工大大岡山キャンパスで開催されたPerlのカンファレンス、YAPC::Asia 2009に参加してきました。 昨年は2つのセッションをやらせて頂きましたが、今年は1つだけ発表をしましたので、資料を公開します 大規模画像配信とPerl SlideShareで公開しています。 大規模画像配信とPerl View more documents from kazeburo. 一部アニメーションを利用していますので、PowerPointもあわせて参照してください。 mixiの画像配信については、このブログや技術評論社様の雑誌等を通して何度か紹介していますが、今回は携帯向けの画像配信、特に画像の動的変換について取り上げました。 画像を扱うライブラリはいくつも種類があり、変換速度や変換後の画像に違いがあります、今回の発表ではその比較もしていま
nginxのX-Accel-Redirectを使った縮小画像配信サーバ - Studyplus Engineering Blog
インフラまわりを担当しております。id:rmanzokuです。 今回は、画像配信サーバをnginxを使ってプチリプレースをしたので その実装方法を紹介します。 課題と対応 Studyplusでは、ユーザーが投稿した画像や教科書の表紙画像を任意のサイズに縮小し配信する機能があります。 この機能はリリース初期から存在し、Javaで実装されていました。 退職済みメンバーの個人リポジトリのライブラリに依存していることもあり、メンテナンスコストが非常に高くなっていました。 （皆さんもそういう経験ありますよね？） リリース初期では、複数の機能を搭載したJavaアプリケーションでしたが現在では 画像管理テーブルからリクエストされたIDに対応する画像ファイルのURLを取得する そのファイルをクエリ文字列で指定した任意のサイズに縮小しユーザーへ返答する という非常にシンプルな機能しか残っていませんでした。
CloudFront+S3の画像配信システムに、サムネイルとかに使う画像のリサイズ機能を追加してみる。 要するにオリジナル画像がこのURLだとすると、 http://xxx.cloudfront.net/sample.jpg こういうURLで100×100にリサイズできるようにする。 http://xxx.cloudfront.net/resize/100x100/sample.jpg システム構成 元の構成はこういうのを想定。 画像はS3に保存され、アクセスは全てCloudFront経由。 これをパスが/resize/で始まる場合は、画像変換サーバを通してリサイズするようにする。 画像変換サーバはEC2で、ちゃんとELBを使って冗長化もする。 既にELB+EC2でAPPサーバを運用しているなら、流用して追加コスト0で実現できるかも。 画像変換サーバの設定 今回はnginxのimage_f
http://d.hatena.ne.jp/yamaz/20060426 の続き.待ち行列理論に従うと遅延のないサービスを行うためには サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数 という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい. ところでたいていのBlogや画像サービスのサービスURLはこうなってる. http://ホスト名/<ユーザ名>/ http://ホスト名/id?ユーザ名 http://ホスト名/ディレクトリ名/コンテンツ名 例で言うと下記のような感じだ. http://d.hatena.ne.jp/yamaz/ http://mixi.jp/show_friend.pl?id=128497 http://i.yimg.jp/images/search/head
また、RAIDカードのパラメータはWritback、bs/512K、マウントパラメータはnoatime,nobarrier、queue_depthなども設定しています。 リニューアル構成 現在、上記の構成をリプレースしており 次期には分散ファイルシステムのOpenstack Swiftを使用した構成になります。 Swiftに関しては最近話題なので、ここでは割愛します。 ちなみにSwiftを採用した理由としては、こんな感じです。 ・分散できる(*´ω｀*) ・RESTful(*´ω｀*) ・pythonでかかれてる(*´ω｀*) ・自動復旧機能がある(*´ω｀*) ・コミュニティが活発(*´ω｀*) ・試験的にもよかった(*´ω｀*) まず分散できるという点。 Swiftはデフォルトで3つのレプリカを持つことができます。 また、zoneという概念をもっており、同じオブジェクトは複数のzone
※ Fastlyの公式イベント「Yamagoya 2021」で発表した内容を再編した記事です。 今回はFastly Image Optimizerを活用したnoteでの画像配信効率化についてお話します。よろしくお願いします。 note株式会社の和田と申します。 2019年4月にnoteに入社し、現在は法人向けサービスであるnote proの基盤システム開発のチームリーダーを担当しています。 Fastly導入前の画像配信における3つの課題noteでは画像配信に多くの課題を感じていましたが、エンジニアの人数が少ない時代もあり、なかなか手がつけられていないのが現状でした。 まずは、Fastly導入前にどのような問題があったのか、画像配信における3つの課題について説明していきます。 1つ目の課題は、アプリケーションサーバーへの負荷です。 noteはサーバーサイドをRailsで実装しており、Carr
合宿で青い人に mod_xsendfile を教えてもらって「あわせて読みたい」に入れてみたら結構いい感じなのでメモ。 ■mod_xsendfile とは PHPなどのスクリプトから静的なファイル（画像ファイルなど）を送信するときに使う便利な apache モジュール。 ■仕組み header("X-Sendfile: （画像ファイルパス）"); と出力すれば、X SendFile がローカルから画像ファイルを引っ張ってきて、Last-Modified などのヘッダ情報をつけて後の処理をしてくれる。 つまり、スクリプトを使っていながら簡単に静的なファイルを送信しているように見せることができる。 （※セキュリティ設定に関係なく、任意のパスを指定できるところがミソ） ■「あわせて読みたい」では これまで、Location: ヘッダをつかってリダイレクトして画像を表示させていた。 この方式の欠点
こんにちは。takutaka と申します。最近良かったことはMOTHER3をクリアしたことです。 最近、画像配信を WebP に動的変換するという施策を担当したので、その話をします。 ペパボにおける画像配信 GMO ペパボでは、クリエイターさんがアップロードした画像でTシャツなどのステキなアイテムが販売できる SUZURI というサービスや、EC支援サービスであるカラーミーショップやハンドメイドマーケット minne など、様々なサービスを運営しており、それぞれに画像の扱いは特徴があります。 SUZURI では、クリエイターさんに提供いただいた画像をペパボで独自で合成し画像を作成していますが、対してカラーミーショップや minne では、ショップオーナーさんや作家さんがペパボのシステムアップロードした画像をエンドユーザーさんに配信しています。 施策を実施したサービス 今回はEC支援サービス
画像配信の負荷分散も比較的簡単？（その2）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim
Cloudflare Workers + R2で低コストで画像配信を移行した話/cloudflare_workers_r2_migration
Workers Tech Talks #1 #workers_tech https://workers-tech.connpass.com/event/287490/ で発表した 「Cloudflare Workers + R2で低コストで画像配信を移行した話」の資料になります。 元ネタに…
minne の画像配信システムのリアーキテクトと作品画像の画質向上ついて - Pepabo Tech Portal
minne 事業部のシニアエンジニアリングリードのshiro16です。最近は年末に組んだ PC でずっとエオルゼアを旅しています。 少し時間が経ってしまいましたが、昨年 minne では画像配信のシステムのアーキテクチャを刷新しました。 更にユーザが登録した作品画像を配信する際の画質の向上を行ったのでその内容をご紹介いたします。 画像配信システムのリアーキテクト そもそもリアーキテクトが必要になった経緯なのですが、以前の構成では okara と呼ばれる内製のツールが使われていました。okara に関しての詳細は弊社 yano3 が公開している資料を参考にして頂ければと思います。 長年 okara を使って来た訳なのですが yano3 が技術部から EC 事業部に異動した事により以前よりメンテナンスに時間を割けなくなってしまったという理由があり、okara のメンテナンスを事業部で行っていく
こんにちは、インフラストラクチャ部の橋本です。 このエントリは GREE Advent Calendar 2015の12日目の記事です。 はじめに グリーではOpenstack Swiftを使いSNSの画像の配信を行っていました。構成は下記のようなもので、WebDAVにWarp（Haskellで書かれていています）、一時的なキャッシュにはFlareを、恒久的な保存にはSwiftを使用しています。このたびSwiftからAWSのS3に切り替えることになりました。その引越にまつわる話です。 SwiftとS3は別もの（当たり前ですが） Swiftを採用される理由としてS3のAPIと互換というものがあります。しかし、それなりの規模で運用するには、バケット(Swiftの用語ではコンテナ）の構成に別々の工夫が必要です。 Swiftはバケットをほぼ無制限に作れます。その一つのバケットのファイルリストはSQ
WEARにおける画像配信のリプレイス戦略とAkamai Image & Video Managerの導入 - ZOZO TECH BLOG
こんにちは、WEAR部の繁谷です。SREとしてWEARの運用・保守・開発をしています。 WEARでは、以前の記事で説明した通り、画像配信のリプレイスを行ってきました。本記事ではSRE観点で画像配信のリプレイスやAkamai Image & Video Manager（以下、Image Manager）を利用した画像リサイズの導入の事例を説明します。 techblog.zozo.com WEARにおける画像配信の課題 前述の記事でも紹介している通り、リプレイス前のWEARの画像配信は下図の構成でした。コーディネート投稿時などのタイミングでIISのAPIを叩き、オリジナル画像をS3に保存します。その書き込みをフックとし、オリジナル画像をリサイズするAWS Lambdaが実行され、派生画像を作成します。そして、作成された派生画像をCDNで配信します。 図1 : リプレイス前の構成図 しかし、この
EC2とVarnishで画像配信
The document discusses using Varnish to cache images on EC2 instances to improve performance for a tofu image processing and delivery system. It describes challenges with using the default memory-only storage for Varnish and switching to a file-based persistent storage model. Using Varnish helped improve performance by caching images, reducing load on application servers and S3. Scaling out to mul
この記事は Cloudflare Advent Calendar 2022 の23日目の記事です 今までブログの画像配信サーバーとして Google Cloud Storage を使っていたが、ブログを Cloudflare Pages に移行したこともあり、どうせならと画像のホスティングも Cloudflare R2 に移行することにした R2 が GA （一般公開）され、パブリックアクセス（独自ドメイン可）ができるようになったのも理由の一つにある（今までは Cloudflare Workers 経由でしかパブリックアクセスできなかった） Cloudflare R2 とは 簡単にいうと、エグレス料金の掛からない Amazon S3 互換のオブジェクトストレージ 料金体系 ストレージ: 月額 $0.015 / GB クラス A 操作: 月額 $4.50 / 100万回 クラス B 操作:
こんにちは。9月よりインターンとして参加しているインフラグループの幸田です。 現在リブセンスでは、高速化の取り組みを進めており、その一環として今回は画像配信システムへのCDN導入検証を行いました。 この記事では導入検証を通して見つけた、最低限確認しておきたい キャッシュヒット率 に関わる設定を2つ紹介します。 検証の背景とか ステージング環境での検証 というフェーズで、インターン課題として取り組みました。 最低限キャッシュを無視する設定(PASS設定)しかされておらず、まさに「とりあえず通してある」という感じです。 ここから本番環境へ導入を進めるための導入検証をはじめました。 前提とか設定とか 前提として、今回導入検証を行うのは画像の配信を専門に行う 画像配信システム です。 CDNには Fastly を使用しました。 (以下Fastlyに合わせて画像配信システムのことを Origin と
海外展開を目指すアプリで実装したセキュアで高速な画像配信の話 / Image distribution for overseas
iOSDC Japan 2018発表資料です。
大規模画像配信とPerl
1. The document discusses various image processing libraries and tools including Image::Magick, Imlib2, and Epeg. 2. It provides code examples for resizing, scaling, and writing images using these libraries. 3. Benchmark results are shown for operations performed with each library, such as reading and writing files, to compare performance.Read less
Ameba を支える画像配信システムとそれを支える Lsyncd の話 | CyberAgent Developers Blog
この記事は CyberAgent Developers Advent Calendar 2016 の 17 日目の記事になります。16日目は No_oLimits さんの MySQL5.7でMHAとmysqlfailover試した でした。 みなさん、はじめまして。16年新卒入社の桐井です。 技術本部というところで、 Ameba の基盤システムを中心にインフラ業務に関わっています。 腰がいたいです。渋谷近辺でオススメの整体があれば教えてください。 今回は、私の配属後のミッションの 1 つである、 Ameba を支える画像配信システムの stat100 の構成刷新について書いてみたいと思います。長いです。 よろしくお願いします。 Ameba を支える画像配信システム “stat100” アメブロやガールフレンド(仮) など、Ameba が提供するサービスやゲームで使われる画像配信システムのう
Webサービスを開発する場合、画像配信はtoB/toC問わず必要になることが多いです。人財活用プラットフォームHRMOSの評価管理は2019年にリリースされた機能ですが、データ連携・インフラ整備・セキュリティ強化など、リリースに向けて様々な準備が必要でした。今回はその中から、AWSのサーバーレスを活用して、セキュアに画像を配信する仕組みを構築した時の取り組みをご紹介します。 画像配信を新たに構築した経緯 評価管理をリリースするにあたり、従業員データベースに設定されている顔写真を評価管理に取り込んで、プロフィール画像として利用可能にすることになりました。PoCの段階では、プロフィール画像はユーザーが任意に設定できる画像しかなかったため、画像配信はSNSのプロフィール画像のような公開画像が前提で作られており、以下のような構成でした。 顔写真は個人情報に該当するためセキュアに配信する必要がありま
暮らしニスタの画像配信サーバを Oracle Cloud に移行して 3 ヶ月ちょっと経過しました - WILLGATE TECH BLOG
はじめに 今までの構成について ホスティング先の選定 ConoHa さくらのクラウド Oracle Cloud 構成の検討 サーバの構築 移行作業 移行作業を終えて おわりに はじめに こんにちは！ インフラチームの高畑です。 最近のコロナ自粛で自宅にいることが多くなっている今日この頃、みなさまはいかがお過ごしでしょうか。 私は最近 DIY にハマっていて大きめの机を作ったりして割と楽しんでいたりします。 さて、今回は全ての主婦の味方で月間総 PV 4000 万を誇る「暮らしニスタ」の画像配信サーバを Oracle Cloud へ移行して 3 ヶ月ちょっとが経過したので、どのように移行したのかなどをご紹介しようと思います。 kurashinista.jp 今までの構成について 1 年ほど前、さくらのクラウドで稼働していた暮らしニスタのサーバ群を AWS へと移行し、各種画像は EC2 に構
画像配信
志田未来(486) 松尾 由美子(1931) 加藤 真輝子(436) 宇賀 なつみ(779) 矢島悠子(906) 大木優紀(536) 上山千穂 (1384) 武内絵美(914) 堂 真理子(1440) 市川寛子(1046) 下平さやか(1607) 久冨慶子、小川彩佳(75) 佐分・八木・本間・竹内(228) 大江真理子・松丸友紀(140) 岡村仁美(1476) 平井理央(449) 笛吹雅子(1286) 半井小絵 (831) 日本テレビ (1237) ＴＢＳ (992) フジテレビ (2277) テレビ朝日 (1317) テレビ東京(575) フリーキャスター、地方局、NHK(837) Berryz工房、℃-ute(338) スポーツ(1003) アイドル・歌手(591) 女優(667) その他 Ⅰ(1573) めざましテレビ系モデル(442)
AppEngineに画像ファイルをアップロードする場合、 DatastoreにBlobとして保存し、表示するときはDatastoreから取り出したデータを Responseに流し込むことで表示するのが今までのやり方でした。 この表示は非常に遅く、問題でした。 SDK1.3.0で追加されたBlobstore APIを使うと、 http://code.google.com/intl/en/appengine/docs/java/blobstore/overview.html Picassaのインフラから配信されるらしく非常に高速になるとの事でしたが、 Slim3のasStringが動かない（？）、処理結果は必ずredirectしなければならない（validate情報をforwardできない）、など 既存のアプリに組み込むには苦労がありました。 しかしながら、SDK1.4.3に追加されたFile
画像配信の負荷分散も比較的簡単？（その5）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. さて前置きが長くなったが,本題に入ろう. アクセスが特定の画像に集中した場合には問題が出ると思うのですが どのように対応したらよろしいでしょうか？ 例えばある画像が1枚某ブログにウプされて 2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり 1台の画像鯖に負荷が集中しさばききれなくなった場合、 先生の方法ではいくら鯖を増設しても負荷は分散されないし アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で 負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも めんどくさいと思うのですがこの辺はどのようにしているのでしょうか？』 特定の画像のアクセスが多くなっ
Railsで運用しているサービスの画像配信をAWSスタックからCloudinaryに移行した話 | スペースマーケットブログ
こんにちは、先週末に宮城県で開催されたツール・ド・東北というサイクリングイベントで100km走ってきて全身筋肉痛の状態で記事を書いているエンジニアの小林です。 先日、スペースマーケットがサービス上で表示している画像を、AWSのS3をオリジンサーバとしてCloudFrontをCDNとして配信する構成からCloudinaryという外部サービスを使って配信する構成に変えました。今日はCloudinaryの紹介とどうやって移行したかの話をしたいと思います。 Cloudinaryの紹介 on the flyな画像変換 Cloudinaryはホスティング型の画像配信サービスでCloudinaryのストレージに画像をアップロードするだけでクライアントの要求(URLに条件を指定する)に応じてon the flyに画像を変換して返することができるようになります。 オリジナルの画像のURLがこちらだとします。
気象衛星「ひまわり」の画像配信できず NHKニュース
気象衛星「ひまわり」の画像が２３日午後から一部の気象会社やテレビ各社などに配信できなくなり、気象庁で原因を調べています。 気象庁の天気予報には影響はないということです。 ２３日午後０時半ごろ、気象衛星「ひまわり」で撮影している画像が一部の気象会社やテレビ各社など民間事業者に配信できなくなったほか、気象庁のホームページでも表示できなくなりました。 気象衛星の画像は、東京都内にある気象庁の施設で３０分ごとに作成され、民間事業者に配信されていますが、このシステムの一部に不具合が発生しているということです。 このシステムを使わないで気象衛星のデータを配信する仕組みもあり、影響が出ていない気象会社もあるということです。 気象庁の天気予報にも影響はないということです。 気象庁は、「衛星画像を利用している事業者のみなさまにご迷惑をおかけして申し訳ありません」と話していて、原因を調べるとともに復旧作業を急
画像配信の負荷分散も比較的簡単？（その4） のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. 画像配信の負荷分散も比較的簡単？（その3）にて下記のようなコメントをいただいた. アクセスが特定の画像に集中した場合には問題が出ると思うのですが どのように対応したらよろしいでしょうか？ 例えばある画像が1枚某ブログにウプされて 2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり 1台の画像鯖に負荷が集中しさばききれなくなった場合、 先生の方法ではいくら鯖を増設しても負荷は分散されないし アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で 負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも めんどくさいと思うのですがこの辺はどのようにしているのでし
CrowdStrikeがセキュリティ上の失敗を表彰する「Pwnie Awards」を受賞しました。Pwnie Awardsの受賞者は授賞式を欠席するのが慣例ですが、2024年8月11日に開催されたPwnie Awards 2024の授賞式にはCrowdStrikeのマイケル・セントナス社長が出席し、トロフィーを受け取る一幕がありました。 CrowdStrike President Shows Up to Accept 'Most Epic Fail' Award at DEF CON | Extremetech https://www.extremetech.com/internet/crowdstrike-president-shows-up-to-accept-most-epic-fail-award-at-def-con 日本時間の2024年7月19日(金)に、CrowdStrike
画像配信サーバを運用していますが、アクセス数急増により、表示が遅いというクレームが入って困っています。。最適なApacheのpreforkの設定など負荷を下げることができる対策方法を教えて下さい。 [サーバー状況] access_logの行数ベースで平均160req(行)/sec 一日1000万req(行) 画像平均サイズは1kbyte [スペック] CPU Sempron 2600+ メモリ 512MB HDD 40GB サーバー1台 [状態] KeepAlive Off StartServers 10 MinSpareServers 40 MaxSpareServers 100 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 400000 procs -----------memory---------- ---swap-- ---
簡単アクセス制限画像配信について - Hatena::Diary::Neko::kak 500 Internal Server Error
画像を配信する仕組みを考えたとき、 htdocsに画像を配置してしまうとだれでも好きなだけアクセスできてしまいますね。 まぁ、サイトのデザインとかで使っている素材であればいいんですが ちょっとしたアクセス制限をかけたい素材な場合、 普通にhtdocsに配置して公開すると問題なわけです。 そういうケースの場合は今までMogileFSをつかって ファイルを管理していたのですが、諸事情によりmogileは使わないで 管理できないかというのを考えてみました。 要件としては 素材の管理で冗長構成をとらなくてよい アプリ側で認めたファイルだけ提供する です 個人的にはPerlbalを良く使っているので Perlbalでためしてみました。 処理の流れとしては、 sv.intraがサービスを提供しているvhostでユーザはこのvhostに対して色々リクエストを投げてくるとします。 sv.intraはpla
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
mixi Engineers’ Blog » ロングテールな画像配信 その1
画像配信の負荷分散も比較的簡単？（その4） - 最速配信研究会(@yamaz)
CloudFront+S3の画像配信にリサイズ機能を追加する - 俺たちのブログ
画像配信の負荷分散も比較的簡単？（その2） - 最速配信研究会(@yamaz)
『出、出、出〜ameba画像配信奴〜！！』
Fastlyを活用したnoteの画像配信効率化 #yamagoya2021｜note株式会社
mod_xsend_file で画像配信サーバーの負荷軽減 : 管理人@Yoski
画像配信を WebP にした際にやったことと困ったこと - Pepabo Tech Portal
画像配信の負荷分散も比較的簡単？（その3） - 最速配信研究会(@yamaz)
画像配信：SwiftからS3への引越について | GREE Engineering
ブログの画像配信サーバーとして Cloudflare R2 を使う | 高木のブログ
画像配信システムにCDNの導入を試みた話 - LIVESENSE ENGINEER BLOG
Serverless Image Handlerによるセキュアな画像配信の実現
GAEの画像配信を速くする方法 - 市中弾き語りの刑
PHSを活用した農園向け画像配信サービス「ミエファーム」
画像配信の負荷分散も比較的簡単？（その6） - 最速配信研究会(@yamaz)
画像配信の負荷分散も比較的簡単？（その5） - 最速配信研究会(@yamaz)
インターネットアーカイブが画像配信標準化フレームワーク「IIIF」を採用したサービスを正式に開始 - GIGAZINE
画像配信サーバを運用していますが、アクセス数急増により、表示が遅いというクレームが入って困っています。。…