ブックマーク / www.na3.jp (19)

  • デブサミ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 オンプレミス、仮想化環境は使っていない ネットワーク通信量が非常に多い 低レイテンシを求められている ハイパフォーマンスを実

    デブサミ2017「グランブルーファンタジーを支えるインフラの技術」講演メモ #devsumi - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2017/02/16
  • サイバーエージェントを退職します - 元RX-7乗りの適当な日々

    私事ですが、タイトルの通り、(株)サイバーエージェント退職します。昨日8/31が最終出社でした。正確に書くと退職日はもう少し先です。 入社日が2010/09/01だったので、ちょうど丸5年が経ちました。在籍中は、社内外の皆様に多くのご協力を頂き、様々なことにチャレンジすることができました。当にありがとうございました。 5年もやっていると、それはもう毎日飽きないくらい良い事も悪い事も色々ありましたが、エンジニアとして技術面、および人間として考え方の幅が大きく広がったと思っていて、良い成長機会を頂けたと思っています。 会社として伸び盛りの重要な大規模サービスやプラットフォームサービスに大きく関われた事、様々な技術的挑戦をさせてもらえた事、その上でそれなりの事業貢献ができた事、そして多くの優秀なメンバーと共に刺激を受けながら仕事ができた事、その全てが素晴らしい経験となりました。 私がやってき

    サイバーエージェントを退職します - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2015/09/02
    なんと
  • 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/

    NVMe SSDのベンチマークをとってみた (約70万IOPS/1台) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2015/09/01
  • 「開発生産性を上げるためのデプロイ戦略」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々

    メモった。間違い等あるかもしれませんが、その場合はごめんなさい。 デプロイとは あらゆるコードやバイナリ、アセットなどの配布をデプロイと定義 インフラストラクチャーの構築はプロビジョニングとする なぜデプロイに注目する必要があるのか AWSのイノベーションのペース 合計1000以上の新サービス、新機能をリリース フィードバックループを回し続け、顧客の期待に応え続ける Amazon.comのデプロイ 平日のデプロイ間隔 11.6秒 1時間あたりの最高デプロイ回数 1079回 1回のデプロイで平均10000台のホストに変更を加える 1回のデプロイで最大30000台のホストへの変更 Two pizzaルール 1チームの大きさは、2枚のピザで全員お腹いっぱいになれる規模 それを保って頻繁にデプロイできるレベルに 作った人が運用をやるポリシー クロスファンクショナルチーム 各チームメンバーが何ができ

    「開発生産性を上げるためのデプロイ戦略」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2015/06/03
    スケールがすごい
  • General Purpose(SSD)なEBSボリュームのベンチマーク追試(バースティング終了後の性能) - 元RX-7乗りの適当な日々

    先日のエントリ「新しいSSDベースのEBSボリューム(General Purpose)のベンチマークをとった」で、最近発表されたAmazon EBSの新しいタイプのボリュームである「General Purpose (SSD)」のベンチマークをとりましたが、このエントリの最後で、 次回予告(宿題)として、バースティングできるクレジットを使い切ったときにどの程度のパフォーマンスになるかを挙げておきますw 新しいSSDベースのEBSボリューム(General Purpose)のベンチマークをとった - 元RX-7乗りの適当な日々 と挙げていたので、続きをやってみたログです。 (General Purpose (SSD)の基礎ベンチマークについては、前回のエントリをご覧ください。) 前提 前回のエントリとほぼ同じ条件で、EBSボリュームのサイズを"50GB"にしてやってみました。 理論値として、B

    General Purpose(SSD)なEBSボリュームのベンチマーク追試(バースティング終了後の性能) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2014/07/13
  • 「MySQL Casual Talks vol.6」に参加してきた&資料まとめ #mysqlcasual - 元RX-7乗りの適当な日々

    久しぶりにMySQLガチュアルカジュアルに参加してきたので、そんなログと資料をまとめておこうと思います。 zusaar.com -&nbspzusaar リソースおよび情報 尚、このイベントの過去の参加記録は以下。 「MySQL Casual Talks vol.1」に参加してきたよ、のメモ 「MySQL Casual Talks vol.2」に参加してきたよ、のメモ 「MySQL Casual Talks vol.3」に参加してきたよ、のメモ 「MySQL Casual Talks Vol.4」のエア参加レポート vol.4がエア参加で、vol.5・・・っていつやったの。。。な感じで久しぶりに参加させていただきました。 TokuDB試してみる (@yoku0825) TokuDB試してみる from yoku0825 TokuDB、InnoDBの3倍くらい圧縮が効くとのことで、レイテンシ

    「MySQL Casual Talks vol.6」に参加してきた&資料まとめ #mysqlcasual - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2014/07/12
  • デブサミ2014「さくらのクラウド開発と運用、裏話的な何か」講演メモ #devsumi - 元RX-7乗りの適当な日々

    クラウドサービスがどのように作られることになったか、とかどのように開発されたかの裏話。生々しい話も所々出てきて面白かったです。 運用の部分、時間がなくなってしまって割愛されていたのですが、そっちも是非聞きたかったです。 「さくらのクラウド開発と運用、裏話的な何か」 鷲北 賢 氏 @ken_washikita さくらインターネット研究所 所長 さくらのクラウド開発チームリーダー兼務 「中間管理職PMの立場でお話します。」 さくらインターネット データセンターを中心とした事業。 ハウジング レンタルサーバ 専用サーバ VPS クラウド(IaaS) 2009/05 「さくらはVPSをやらない」と高らかに宣言(したように見えた) 社長が当時の@ITにて 現実として、社内に仮想化サービスを検討するプロジェクトは皆無 社長の記事のおかげで、「やっちゃいけないんだな…」という空気が醸成 2009/07

    デブサミ2014「さくらのクラウド開発と運用、裏話的な何か」講演メモ #devsumi - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2014/02/15
    「社長がプロトタイプ作ってきた」
  • nscdが保持しているキャッシュをクリアする - 元RX-7乗りの適当な日々

    hostsファイルの記載に誤りがあるまま、telnetコマンドを実行した。 で、誤りに気付き、hostsに記載のIPアドレスを修正し、telnetコマンドを再度実行したが、なぜか古い記載のアドレスに接続しにいく。 むむっ、と思って、straceしてチェックしたら、 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0↑の通り、nscdを見に行っておった。 # nscd -i hostsということで、↑のような感じで、nscdの持っているhostsのキャッシュを破棄して、無事期待通りの動作になった。 ・・・たまに調べるから、ここに残しておく。 それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́ 追記 やっぱりそうだよなぁ。うーむ。 デーモンは( pas

    nscdが保持しているキャッシュをクリアする - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2014/01/28
    nscd に hosts キャッシュはさせていはいけませんね。。。。
  • Amazon EC2で高速SSDを8つも搭載した新しいI2インスタンスのベンチマークをとってみた - 元RX-7乗りの適当な日々

    AWS re:Inventで発表されていた、SSDによる高性能ランダムI/O用に最適化されたという、Amazon EC2の新しいインスタンスタイプ「I2インスタンス」が先日使えるようになりました。 インスタンスタイプとしては"i2.*"からはじまるやつです。 I2インスタンスタイプは、特にリレーショナルデータベース、NoSQLデータベース、およびトランザクションシステムによって生成されるI/O集約型のワークロードをホストするように設計されています。最も大きいサイズのI2インスタンスタイプは、4KBのブロックサイズでの計測で、秒間365,000を超えるランダムリードと秒間315,000を超えるランダムライトの性能を発揮します。4つのインスタンスサイズをご利用いただけますので、必要なストレージとI/O性能が高くなのに合わせて、小さくスタートし、スケールアップしていくことができます。 このインス

    Amazon EC2で高速SSDを8つも搭載した新しいI2インスタンスのベンチマークをとってみた - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/12/24
  • HAProxyのパフォーマンスチューニングをやったメモ(CPS編) - 元RX-7乗りの適当な日々

    HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。 基的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。 あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。 前提 HAProxyを動かすのに使用した環境は以下の通り。 Server: DELL PowerEdge R420 CPU: Intel Xeon E5-2430L @ 2.00GHz * 2 Memory: 96GB Ethernet controller: Intel Corporation Ethe

    HAProxyのパフォーマンスチューニングをやったメモ(CPS編) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/12/21
  • 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モジュールを

    HAProxyを透過型のプロキシとして使う(HAProxy with tproxy) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/12/05
  • 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 EC2インスタンスガチャをやってみました - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/10/02
  • AWS Command Line Interface(awscli)を使ってみた - 元RX-7乗りの適当な日々

    今更な話題ではありますが、Pythonで作られたAWS Command Line Interface(aws-cli: 従来のJavaで動いていたEC2 API Toolsとは別物)を入れて動かしてみました。メモ的な感じで残しておきます。 aws-cliは、pipで管理できるし、これ1つで複数のAWSサービスを扱うことが出来て、かつレスポンスもJSONとかで返ってくるので、なかなか便利です。 $ aws autoscaling ec2 importexport sns cloudformation elasticache opsworks sqs cloudsearch elasticbeanstalk rds storagegateway cloudwatch elastictranscoder redshift sts datapipeline elb route53 support

    AWS Command Line Interface(awscli)を使ってみた - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/08/13
  • AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々

    昨日から、色々調べ始めています。今日はAWSの上位ネットワークまわり。特に東京リージョン(Asia Pacific (Tokyo) Region)。 現時点の情報のスナップショットとしてログがわりに残しておきます。 ASN (AS番号) まず、以下のサイトで調べてみると、、、 http://bgp.he.net/search?search[search]=Amazon&commit=Search この通り、Amazonが取得しているASNは10個ほど見受けられますが、中身を見ていくと、このうちAS16509にほぼ集約されていることがわかります。 AS16509に接続されているBGPのPeerの数は現時点で、v4が158、v6が10となっています。(公開情報のみ) Peerの内訳は以下のリンク先から確認できます。 http://bgp.he.net/AS16509#_peers ざっくり確認

    AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/07/24
  • Chef 11 での client/server/knife のセットアップ手順(+α) - 元RX-7乗りの適当な日々

    遅れながら、Chefの新しい11系のバージョンを触ってみました。 つまづいた途中経過を含めて、セットアップのログや動きで気付いた事を簡単に残しておきます。 尚、今回使ってみた実行環境は、CentOSの6系です(Linux)。 結論から申し上げますと、Chefの新しいバージョンは、サーバのセットアップが物凄く楽でした。 旧来のバージョンでもUbuntuはそこそこ楽でしたが、CentOSの面倒くささと言ったら、んもう。 インストールパッケージの入手先 最近は、下記のChef家となるOpscodeのサイトから、client/serverともインストーラ(各OSでのパッケージ)をダウンロードできるようになっています。 Chef Downloads Clientのインストール 上記サイトからパッケージをダウンロードしてインストールしてもよいのですが、Linuxであれば curl -L https:

    Chef 11 での client/server/knife のセットアップ手順(+α) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/05/27
  • 複数のChef-serverで同一のvalidation.pemを利用させたいとき - 元RX-7乗りの適当な日々

    運用設計・ルール的な是非は一旦おいておいて、複数のChef Serverでvalidation.pem(chef-validatorの鍵)を共通化させたいときに、どうやったかというメモ。ちなみに、バージョン10系での話です。 イメージは、既に1台のChef-serverを運用していて、もう1台新しいChef-serverを足したいんだけど、nodeとなるサーバの運用フローを変えたくないので(面倒くさいので)、validation.pemは共通で使いたいなー、というケース。(これはユースケースによってメリット・デメリットがあります) 僕が探した感じ、APIではその口が用意されていなかった(というか、あるように見えてeditしてみたけど反映されなかった)ので、結論からいうとバックエンドのCouchDBにアクセスして書き換えた感じです。 説明はここまででいいような気もしますが、一応自分のために手

    複数のChef-serverで同一のvalidation.pemを利用させたいとき - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/05/17
    参考になる
  • Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々

    さて、またまた昨日のエントリ「Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編)」の続きです。 ここまでの経緯は以下。 Amazon EBS の性能ベンチマーク その1 (Standard編) Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) ここまでのベンチマークでは、StandardタイプのEBSボリュームを使っていたのですが、ここからは、必要とするIOPSを設定することが可能な"Provisioned IOPS"なEBSボリューム(プロビジョンドIOPSボリューム)を使って性能を計測してみたいと思います。 # 個人で Provisioned IOPS ボリュームを使って高負荷テストとかクラウド破産まっしぐら。 ベンチマークの条件の詳細等は、上記のこれまでのエントリからご確認くださいませ。 今回ベンチマークの対象とす

    Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/04/18
  • Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々

    以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですw) 実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった&今はまた結果が違うかもなので、やってみた。 ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。 というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた -

    Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2013/04/17
  • 「DevOps Days Tokyo 2012」でChefの話をしてきたので資料を公開します - 元RX-7乗りの適当な日々

    5/26(Sat.)に「DevOps Days Tokyo 2012」が日で開催され、その中でご縁を頂きまして日語枠でお時間をもらい、Chefを使った取り組みについて話をさせていただきました。 DevOps Days Tokyo 2012 - welcome このイベントでは、「DevOps Cafe」といった今世界で一番DevOpsの最先端情報が発信されていると言われるPodcastを配信している enStratus の John Willis 氏や、 DTO Solutions の Damon Edward 氏、Chefの開発元である Opscode の George Moberly 氏などといったビッグゲストの話を日国内で聞けるといったDevOpsの祭典ともいえるイベントだったと思います。 その中で僕の話はと言うと、所属している会社で取り組んでいるアメーバピグの運用の話や、その

    「DevOps Days Tokyo 2012」でChefの話をしてきたので資料を公開します - 元RX-7乗りの適当な日々
    wtatsuru
    wtatsuru 2012/06/15
  • 1