デブサミ2017「グランブルーファンタジーを支えるインフラの技術」講演メモ #devsumi - 元RX-7乗りの適当な日々
CAを離れて1年半。最近はどんな感じか知りたかったので聞いてきました。面白かったです。 グランブルーファンタジーを支えるインフラの技術 (株)Cygames 佐藤太志 氏 グランブルーファンタジーについて 特徴 スマホのRPG ブラウザゲーム 協力プレイ、マルチプレイ システム規模 登録ユーザ数1400万人 月間300億PV 100万query/sec 8万req/sec トラフィック12Gbps (CDN除く) システム構成 LBはBIG-IP CDNはAkamai HTTP/WebSocketがフロントインターフェース Web: Apache + mod_php + mysqli Node: Node.js + twemproxy DB: MySQL + MHA オンプレミス、仮想化環境は使っていない ネットワーク通信量が非常に多い 低レイテンシを求められている ハイパフォーマンスを実
デブサミ2016「大規模Redisサーバ縮小化の戦い」講演メモ #devsumi - 元RX-7乗りの適当な日々
メモメモ。泥臭い話で面白かったです。 「大規模Redisサーバ縮小化の戦い」 駒井 祐人 氏 (株)アカツキ ゲームのサーバサイド機能開発、インフラの設計構築・保守運用 Redisとは インメモリDB 5種類のキーバリューのデータ型 ファイル永続化オプション システムの問題点 EC2サーバが20台に対して、AWSのElasticCache(Redis)が64台あった なぜ64台あったかというと、リリース直後にRedisの負荷問題があり、8台 => 64台になった 調査するとkeys("")を実行している箇所があった 当然お金がかかる(cache.m3.large * 64台 = 約135万円/月) 冗長化しんどいし、設定ファイルの記載も辛い ので、縮小化と冗長化の対処をしたい 現状整理 格納されているデータ フレンド情報、セール情報、ランキング情報 キーの件数 1サーバに8DB、1DBあた
サイバーエージェントを退職します - 元RX-7乗りの適当な日々
私事ですが、タイトルの通り、(株)サイバーエージェントを退職します。昨日8/31が最終出社でした。正確に書くと退職日はもう少し先です。 入社日が2010/09/01だったので、ちょうど丸5年が経ちました。在籍中は、社内外の皆様に多くのご協力を頂き、様々なことにチャレンジすることができました。本当にありがとうございました。 5年もやっていると、それはもう毎日飽きないくらい良い事も悪い事も色々ありましたが、エンジニアとして技術面、および人間として考え方の幅が大きく広がったと思っていて、良い成長機会を頂けたと思っています。 会社として伸び盛りの重要な大規模サービスやプラットフォームサービスに大きく関われた事、様々な技術的挑戦をさせてもらえた事、その上でそれなりの事業貢献ができた事、そして多くの優秀なメンバーと共に刺激を受けながら仕事ができた事、その全てが素晴らしい経験となりました。 私がやってき
NVMe SSDのベンチマークをとってみた (約70万IOPS/1台) - 元RX-7乗りの適当な日々
手元にNVMe SSDがあったので、自分でベンチマークを取ってみたログ。 NVMeってのは、ストレージデバイスを接続する際の規格で、従来でいうSATAインターフェースの仲間みたいなもの。NVMeの詳細は以下のリンク先に記載があるので読んでいただきたい。 NVMeは、SCSIやSATA（Serial ATA）と同じく、ストレージを接続するための規格だ。パイプラインやランダムアクセスなど、メモリーベースのストレージであるSSDの特徴を活用できる。また、SATAやAHCIの登場から現在までの間に進化した、データのレイテンシー（遅延時間）短縮のための手法も反映している。 具体的な改良点としては、4KBの転送に必要なメッセージが2つではなく1つで済む点や、コマンドを処理するキューが1つではなく複数になっているという点がある。「複数」というのは、実に6万5536個である。これにより、多数のディスクI/
「サーバにログインしない・させないサービス運用」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
メモった。間違い等あるかもしれませんが、その場合はごめんなさい。 Gunosy 2011.09リリース 現在900万DL突破 エンジニアは現在26名 2014.11は16名、2013.11は7名、2012.11は4名 クライアント+QAは5名、Web+APIまわりは5名、インフラは1名とかとか Gunosyの開発 API: Golang パートナー・広告主への管理画面: Rails バッチ・内部向け: Django or Python バージョン管理: GitHub 構成管理・デプロイ: Chef (+OpsWorks) 開発の特徴 小さい単位で作ってすぐ捨てる マイクロサービス的な 機能が増えすぎたら分割 メンテするよりリプレース サーバにログインされて困る事 信頼できないビルド・デプロイ 開発者の手元でビルドすると、どの断面なのかわからずトラッキングできない プロダクションに上がってい
「Amazon RDS for Aurora Deep Dive」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
メモったので、貼付けておきます。 間違い等あるかもしれませんが、その場合はごめんなさい。 Auroraは現在Preview中 頻繁にデプロイ・機能変更が行われている 今日の話の内容は6/2時点のもの フルマネージドなDB データベースを数分で作成可能 自動でパッチの適用 1クリックでスケールアウト S3への継続的バックアップ Amazon Aurora AWSがクラウド時代にRDBを作るとするとどうなるかを1から考えた エンタープライズグレードの可用性とOSSレベルのコストを両立 現在はLimited Preview Virginia/Oregon/Irelandリージョンで動いている 5/20よりpreviewがプロダクション環境へ移行 Beta環境はクローズ AuroraのPricing 現在は、r3シリーズのみでの提供 ライセンス料金は不要 MySQLと100%互換なので、ロックイン
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
Sensu Serverをインストールする手順メモ - 元RX-7乗りの適当な日々
ゴールデンウィークに突入したタイミングで色々忘れてしまいそうなので、ここにSensu Serverの作り方をメモっておく。 ちなみに、Sensuは最近ナウなヤングにバカうけのモニタリングツール。インストールした環境は、CentOS 6.5 (Linux version 2.6.32-431.11.2.el6.x86_64)。 ちなみに、Sensu関連のインストールについてはChefやPuppetの使用が、推奨されてるっぽいので、今回はChefのCookbookをありがたく利用させていただいた。(このエントリではchef-soloを使って環境構築している。) SensuのChef Cookbookは以下のGitHubリポジトリで公開されている。 https://github.com/sensu/sensu-chef sensu-chefの取得 # yum install -y git gcc
Redis(2.8系)の基本オペレーションとかSentinelの挙動とかの色々メモ - 元RX-7乗りの適当な日々
最近必要に迫られて、ようやくRedisをインストールして触ってみました。(Redis童貞からの脱却) 色々と、基本部分ではあるけど、せっかく実際に触りながら勉強したので、このエントリにメモしておこうと思います。 尚、使ってみたRedisのバージョンは、stableの最新版である2.8.7です。(OSは、LinuxのCentOS 6.5) ちなみに、このエントリに書いていないような、Redisの基本的なアレコレについては、WEB+DB Press Vol.73のRedis特集(2.6向けではありますが)にほとんど書いてあるので読むべし。 WEB+DB PRESS Vol.73 作者: 設樂洋爾,白土慧,はまちや2,大和田純,松田明,後藤大輔,ひろせまさあき,小林篤,近藤宇智朗,まかまか般若波羅蜜,Mr. O,川添貴生,重国和宏,柳澤建太郎,奥野幹也,佐藤鉄平,後藤秀宣,mala,中島聡,堤智
デブサミ2014「さくらのクラウド開発と運用、裏話的な何か」講演メモ #devsumi - 元RX-7乗りの適当な日々
クラウドサービスがどのように作られることになったか、とかどのように開発されたかの裏話。生々しい話も所々出てきて面白かったです。 運用の部分、時間がなくなってしまって割愛されていたのですが、そっちも是非聞きたかったです。 「さくらのクラウド開発と運用、裏話的な何か」 鷲北 賢 氏 @ken_washikita さくらインターネット研究所 所長 さくらのクラウド開発チームリーダー兼務 「中間管理職PMの立場でお話します。」 さくらインターネット データセンターを中心とした事業。 ハウジング レンタルサーバ 専用サーバ VPS クラウド(IaaS) 2009/05 「さくらはVPSをやらない」と高らかに宣言(したように見えた) 社長が当時の@ITにて 現実として、社内に仮想化サービスを検討するプロジェクトは皆無 社長の記事のおかげで、「やっちゃいけないんだな…」という空気が醸成 2009/07
デブサミ2014「グリーにおけるChef導入事例」講演メモ #devsumi - 元RX-7乗りの適当な日々
普段、Chefを使って運用しているので、なかなか参考になる話だったというか、共感できる部分が多かったです。 「グリーにおけるChef導入事例」 荒井 良太 氏 @ryot_a_rai グリー Chefとは サーバの構築や設定更新を自動化するツール サーバのあるべき姿をRubyで記述しておくと、セットアップしてくれる 冪等性 Chef社のOSS 導入背景 運用担当者が秘伝の手順書でサーバのセットアップを手動でやっていた。 非効率 オペレーションミスの危険 Chefにより自動化し、安定運用をはかる リードタイム Chefにより自動化し、サーバのデリバリーを素早く行う Before Chef Debianパッケージ サーバの役割ごとのメタパッケージ 設定ファイルはスクリプトで生成 設定値 パッケージ内 サーバ管理システムに問い合わせ サーバ管理システム 社内のサーバ情報を管理しているシステム サ
デブサミ2014「サーバプロビジョニングのこれまでとこれから」講演メモ #devsumi - 元RX-7乗りの適当な日々
期待通り、面白い話だったのでメモを残しておく。 「サーバプロビジョニングのこれまでとこれから」 宮下 剛輔 氏 mizzy @gosukenator paperboy&co. テクニカルマネージャ サーバプロビジョニングとは プロビジョニングは3つのレイヤがある。 orchestration application service orchestration configuration system configuration bootstrapping cloud or vm image launch os install あまり厳密に捉えすぎる必要はない。とのこと。 Bootstraping 今日は割愛 Configuration ミドルウェアのインストールとか設定とか いわゆる構成管理ツール CFEngine, Puppet, Chef, Ansibleなど 会場は、Chef利用者多
HAProxyを透過型のプロキシとして使う(HAProxy with tproxy) - 元RX-7乗りの適当な日々
HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。 で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。 使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。 参考: Transparent proxy support (www.kernel.org/doc) https://www.kernel.org/doc/Documentation/networking/tproxy.txt Linux kernelのnf_tproxy_coreモジュールを
Amazon EC2インスタンスガチャをやってみました - 元RX-7乗りの適当な日々
歴史のあるクラウドサービスは、どこもそうなってしまう傾向があるとは思いますが、ホストサーバでの実CPUのアーキテクチャ・世代の違いで、サーバインスタンスのCPUパフォーマンスに微妙な差がついてしまいます。 2006年よりサービス提供しているAmazon EC2でもその傾向があることは割と知られていて、同じ性能だと思って並べて使っていたサーバインスタンスが、同じ処理量にもかかわらず使っているCPUリソースに差がついている、なんてことが起こります。 con_mameさんも、以下のエントリで書かれていますね。 EC2で同じECUだけどCPUは違う - まめ畑 昔は、us-eastでm1.smallのインスタンスをよく使ったもので、その頃はいつもAMDのOpteronプロセッサでしたが、最近では、ほとんどIntel Xeonですし。 ということで、現時点(2013/10)で、EC2インスタンスで使
Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々
以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですｗ) 実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった＆今はまた結果が違うかもなので、やってみた。 ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。 というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
