タグ

infrastructureとserverに関するsomatのブックマーク (6)

  • これが5年間の技術的失敗と成功の歴史、GREEの成功を支えた技術者たちの闘いが今明かされる

    「2007年からソーシャルゲームを提供してきたGREEにおける、技術的な側面での失敗と成功の実例を通じて、そのノウハウや必要な技術について解説します。合わせて、それらの経験に基づくGREEから提供していくフレームワークであるGREE Technology Stackについてもご紹介します」ということで、CEDEC2011にて講演された「GREEソーシャルゲーム5年間の技術的失敗と成功の歴史 ~GREE Technology Stackのご紹介~」はかなり濃い内容となっており、グリーの開発部 取締役 執行役員CTO 開発部長である藤真樹氏と、同じくグリーの開発部 インフラ統括部 アプリ基盤チーム リーダーの梶原大輔氏による話が次々と展開されていきました。 注目度も非常に高く、人だらけ。 今回はこの講演を発表の場にいる感覚で読んでもらえるように、当日の発表資料と合わせてまとめてみました

    これが5年間の技術的失敗と成功の歴史、GREEの成功を支えた技術者たちの闘いが今明かされる
  • グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering

    はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる

    グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
  • CentOSで自宅サーバー構築

    ルーター経由接続によるインターネット常時接続環境である(当サイトはIIJmioひかりによるインターネット常時接続環境) 固定または非固定のグローバルIPアドレス環境である(当サイトはGMOとくとくBBの固定グローバルIPアドレス環境(逆引きも可能)) ※メールサーバーを構築する場合は逆引き可能な固定グローバルIPアドレス環境が望ましい(非固定グローバルIPアドレスや、固定グローバルIPアドレスでも逆引きしたホスト名とメール送信元ホスト名が異なる場合にメール受信を拒否するメールサーバーがまれに存在するため) OSのインストール時を除き、サーバーの操作はWindowsからコマンド操作で行なう ■コンテンツ ※ホスト名やドメイン名、IPアドレスは各自の環境に置き換えること ※各目次に表記してあるバージョンは、当サイトで確認をとったCentOSのバージョンを示しており、そのバージョンでないとできな

  • livedoor Techブログ : nowaのサーバ構成

    こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ

  • とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする

    すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定

    とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
  • High Scalability | Building bigger, faster, more reliable websites.

    Brief History of Scaling Uber This blog post was written by Josh Clemm, Senior Director of Engineering at Uber Eats. This is a repost from his LinkedIn article, approved by the author. On a cold evening in Paris in 2008, Travis Kalanick and Garrett Camp couldn't get a cab. That's when Behind AWS S3’s Massive Scale This is a guest article by Stanislav Kozlovski, an Apache Kafka Committer. If you wo

  • 1