オンラインゲームの仕組みと工夫オンラインゲームの仕組みや工夫を調べてみたのを社内勉強会で発表した。ときのスライド。の公開用。 オンラインゲームの種別とそれぞれの仕組みについての話と、オープンソースになっているQuakeの仕組みの話、という2つの話が主なトピックRead less
AWS-CloudDesignPattern CDP2.0候補
AWSクラウドデザインパターンとは？ AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC Engineers' Blog
入社4年目にもなってtech.kayac初登場のせいです。 ブログ書けプレッシャーにとうとう屈する時がきました。 これで夢にkyo_agoが出てうなされなくてすみます。(彼はtech.kayacの尻たたき担当でした) 先々月「ぼくらの甲子園!熱闘編」というゲームをモバゲー内にてリリースしました。 これは去年リリースした「ぼくらの甲子園!」の続編です。 モバゲーユーザの方、是非遊んでみてください。 今回はこの「ぼくらの甲子園!熱闘編」がどういうインフラ構成になってるか紹介したいと思います。 注) 題名に「カヤック流」とはつけましたが、カヤックでは多様性を善としている風潮があり、 ゲームによってインフラの構成が違うどころか、利用しているプログラミング言語すら違います。 なので全てのゲームがこのような構成になってるわけではありません。 前提 今回のインフラ構成を決めるに至って考慮した点は「ラクに
Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること - blog.nomadscafe.jp
Webアプリケーション内で処理を直列に実行せずにJob Queueに回して非同期に実行することが多くなって来て久しいと思いますが、そのおすすめ構成と気をつけることについてつらつらと。 1) 既存のデータベースをキューとして使う構成例 １つ目はMySQLなどのデータベースをキューとして用いる例。既にアプリケーションで利用しているデータベースにキュー用のテーブルを作成して利用します。データベースを利用したキュー管理の仕組みとしてJonk、Qudo、TheSchwartzなどがPerlでは有名どころです。 依存するミドルウェアが増えないので最もシンプルな構成になると思います。 上記の図ではWorkerはアプリケーション内で実行することで冗長性を確保しますが、キューを格納するデータベースはSPOFになります。しかし、、データベースに障害があった場合キューだけでなくすべてのサービスが停止すると思われ
techbank.jp - このウェブサイトは販売用です！ - techbank リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
- PukiWiki
linux での仮想化 † 一時期は xen がもてはやされていたが，開発の流れの問題で linux 関係はほとんど kvm に流れてしまった模様．(2010/01) ↑ ゲストOS のインストール † ホストOSと同じ環境を用意するならば，ubuntu-vm-builder コマンドを使うと良い． ex) ubuntu-vm-builder kvm jaunty -o -v --dest=test1 --domain test1 --arch amd64 \ --hostname test1 --mem 512 --ip 203.143.124.182 --mask 255.255.255.248 \ --gw 203.143.124.177 --dns 203.143.124.177 --libvirt qemu:///system \ --addpkg openssh-server
Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法
監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載！ [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規
ポーリングについて(+POEでepoll/kqueueを使う方法) - hogeistの日記
先日のサンプルもそうでしたが、POEもデフォルトではポーリングにselectを用います。 selectのコストは接続数に比例します。N人接続しているとき、各々にN倍のコストがかかるので、全体ではO(N**2)のコストがかかります。 それに対して新しい方式のepoll (BSD系ではkqueue)では、コストが接続数に比例しません。N人接続しているとき、全体の負荷はO(N)になります。 例えば10人接続している時と100人接続しているときのポーリングの負荷の違いを考えると selectの場合 接続者数が10倍で、負荷は10×10の100倍！ epollの場合 接続者数が10倍で、負荷も10倍。 というかなり大きな違いが出てきます。数が少ない内はselectでも全く問題ありませんが、人が増えてくると顕著に負荷が違います。 (実際にベンチマークした結果がlibeventのサイトにあります) と言
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
Running Quercus in Jetty Web Server
Jetty Web server can be invoked and installed as a stand alone application server. It has a flexible component based architecture that allows it to be easily deployed and integrated in a diverse range of instances. The project is supported by a growing community and a team with a history of being responsive to innovations and changing requirements. More info here. Installing Jetty First you need t
shinshu.fm - shinshu リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
#14 (Mailmanをバーチャル環境でインストールする。) – hdknr.com book
以下のようにしてみましたが。。。。 [root@fedora ~]# vi /var/lib/mailman/data/virtula-mailman ml.[mydomain] IGNORE @ml.[mydomain] @[mydomain] [root@fedora ~]# chgrp mailman /var/lib/mailman/data/virtula-mailman [root@fedora data]# cd /var/lib/mailman/data [root@fedora data]# postmap virtula-mailman [root@fedora data]# ls sitelist.cfg virtula-mailman virtula-mailman.db
Postfix + Dovecot + PostfixAdmin + Postgrey + Mailman | with 魂
Postfix + Dovecot + PostfixAdmin + Postgrey + Mailman のインストールメモ （赤字はそれぞれの環境で違います。 ） MySQL 対応の Postfix と Postfix のログ解析ツール Postfix-pflogsumm をインストール yum –enablerepo=centosplus install postfix postfix-pflogsumm MySQL 対応になったかチェック postconf -m | grep mysql mysql と表示されれば OK 自動起動設定 chkconfig postfix –level 3 on postfix を yum の自動更新から外す vi /etc/yum.conf exclude=postfix* sendmail を削除 yum remove sendmail Post
Postfix でメール送信量の制限方法
Postfix でメールの送信量を制限するやり方です。/etc/postfix/main.cf を編集します。 まず1クライアントからの単位時間当たりの送信数を制限する方法です。単位時間のデフォルトは 60 秒で、送信数は無制限です。 # 単位時間は記述しなければデフォルトが60s anvil_rate_time_unit = 60s # 単位時間あたりの送信数を 100 通に制限 smtpd_client_message_rate_limit = 100 単位時間あたりの受信者数の制限もできます。単位時間あたりにこの数の宛先に達するまでメールを送信できます。人間の感覚で10通とか少なめにしすぎてしまうと、CGI やデーモンなどからのメール、メーリングリストなどで使っている場合に制限に簡単に引っかかりますので注意しましょう。 # 単位時間あたりの受信アドレスを 200 通に制限 smtpd
Postfix 設定パラメータ
Postfix main.cf ファイルフォーマット Postfix main.cf 設定ファイルには、Postfix メールシステムの動作を 制御する全てのパラメータのうち、小さなサブセットを指定します。 main.cf で指定されていないパラメータは、そのデフォルト値のまま 残されます。 main.cf ファイルの一般的な書式は以下の通りです: それぞれの論理行は "parameter = value" の形式を取ります。 "=" の前後の空白は無視されます。また論理行の最後の空白も同様です。 空行と空白だけの行は無視されます。また、最初の非空白文字が `#' の行も同様です。 論理行は空白以外のテキストで始まります。空白で始まる行は 論理行を継続します。 パラメータの値は他のパラメータを参照することができます。 "$name" や "${name}"、"$(name)" という表記は
統合監視システム構築(Nagios) - CentOSで自宅サーバー構築
[root@centos ~]# yum -y install gd-devel ← Nagiosに必要なgd-develをインストール [root@centos ~]# useradd -d /usr/local/nagios/ -M nagios ← nagiosユーザー作成 [root@centos ~]# wget https://downloads.sourceforge.net/project/nagios/nagios-4.x/nagios-4.2.4/nagios-4.2.4.tar.gz ← Nagiosダウンロード ※最新版のURLはダウンロードページで確認すること [root@centos ~]# tar zxvf nagios-4.2.4.tar.gz ← Nagios展開 [root@centos ~]# cd nagios-4.2.4 ← Nagios展開先ディ
メールサーバー（SMTP・POP・IMAP）監視を簡単に実現する方法とは？
メールサーバー監視の必要性ビジネスにおいて、メールシステムは今や必要不可欠のインフラとなりました。メールサーバーに問題が発生してメールの送受信がストップした場合、従業員の業務がストップし、大きなビジネス損失へとつながります。 メールサーバーに障害が発生した場合、障害から短時間で復旧してダウンタイムを最小化することが重要です。サーバー管理者は、ビジネス損害を最小限に抑えるため、メールサーバーの各コンポーネントの状態を把握し、潜在的な問題やパフォーマンス低下を事前検知することが望ましいと言えます。 メールシステムのダウンが疑われる場面では、サーバー管理者が疑うべき原因として以下が挙げられます。 外部とメールサーバーまでの間のネットワークの障害メールサーバーが稼働するWindows Serverのサーバーダウンやパフォーマンス障害メールサーバーのシステムダウンやパフォーマンス障害SMTPサーバー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YUM レポジトリの作り方 | 俺履歴-おれろぐ- | RAKUGAKI.jp
postfix: postfixadminでvirtualな環境で特定のアドレス宛メールをスクリプ トに食わせる
ら・う゛ろぐ｜連載-- ホスティングサーバーの再構築 その9