サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Google I/O
6pongi.wordpress.com
デプロイやちょっとした設定変更の際に、オぺレーティングシステムなど、システム条件をもとに固有の処理をしなければならないケースはよくありますよね。facterを使うと以下の様なシステム情報を取得できるので、そういった処理が簡単につくれます。 でもこれじゃ情報不足で中途半端、あんまり使い道ないわー、なんていう反応をしてしまいそうですが、facterは取得する情報をカスタマイズできるので、例えばサーバをファーム分けしている場合ファームIDを取得したり、MySQLのmaster/slaveの区分を取得するなんてことも可能です。 -bash-3.2$ facter architecture => x86_64 augeasversion => 0.9.0 domain => hoge.example.com facterversion => 1.6.1 fqdn => ope.hoge.exampl
RRDなどにメトリクスを書き込んでグラフを生成している場合、標準的なサーバだとCPUかHDDがボトルネックになって、Nagiosサーバ1台あたり持てるクライアントは、300台〜700台くらいが限度といったところでしょう。 数万台のサーバを管理する様な環境では、Nagiosサーバ単位で情報が分断されてしまうので、関連するシステム（特に他部署が管理している様な）の状況が把握しづらいことがよくあります。 全サーバの状況を横断して検索、リスティングができると、障害時の対応時間を短縮できるし、統計情報の取得ができるとメトリクスdrivenな運用＆開発もしやすくなり、プロダクトの質も向上するだろうということでfluentdでやってみました。とは言ってもまだ始まったばかりなのですが、下の図の様な構成で、Nagios上のイベントログをfluentdがtailし、必要なイベントログをfluentd serv
MySQL Beginners Talkに参加してきました。このイベントは、以前に参加したMySQL Casual Talksが、結局皆の予想通りガチだったことから、もっとユルい勉強会が求められているのでは！？ということからBeginnersというタイトルで企画された様です。 実は1週間ほど海外にいて帰国してすぐこの勉強会に出かけたので、かなりの疲労状態。。だったのですが、タイトル通りBeginners向けのセッションもあり、突然のお宝獲得じゃんけんバトルあり、お約束通りのガチもありで楽しめました。 会場は外苑前のオラクルです。ここはもう何度か行ったことがあるので不審者風な動きをすることはなく会場に辿り着きました。 私は今の職場につとめてから昨年の4月までずっとNoSQLのみで構成されたシステムの開発/運用をしていたので、MySQLの経験は実は1年しかありません。4月に異動となり、いきなり
Fluentd Casual Talksに参加してきました。こういった勉強会の情報は、twitterとRSSで素早く把握できる様にしてはいるのですが、申し込んだ時点で補欠40番目というかなり絶望的な状況。。でも当日にキャンセルが続出して余裕で繰り上げ当選となりました！ 会場は先日オフィスを移転したばかりのDeNAのヒカリエオフィスです。外部の人を多数招くのは大変だと思いますが（しかも無料で！）受付も誘導の方々もフレンドリーで余裕のある対応！そういったところ見習わないとな〜なんて思いました。 oranieさんの「fluentdはじめました」 Fluentd casual 大規模で使う様になると困るのがconfigファイルの管理ですよね。ウチの環境でもこのあたりはそのまま真似した方が良いだろうなと思いました。 アプリケーションサーバでは、include httpdでconfig情報を読み込ん
コンピュータの世界、特にインターネットで提供するサービスでは、安定を確認しないままローンチさせ、サービスさせながら質を上げる、まずいところは直すというやりかたがあります。 ただ、課金サービスの場合は、利用できない状況が多発すれば、サービスに対する信用が失われるだけでなく、返金を考えなければならないでしょう。また、現在安定して動作している既存サービスをリニューアルする場合、ユーザは以前以上の安定を期待しているでしょう。 そこで必要となるのがテストですが、機能が期待通りの動作をする事を確認するテストと、パフォーマンスや安定が期待通りである事を確認するものとがあります。 私は現在、運用を担当するエンジニアなので、リリースするサービスのパフォーマンスや安定性を重要視しています。そこで、それらのテストをどの様に行うかを検討しまとめてみました。 1. テスト環境を決める 存在する制約の中で、実運用環境
Pythonとdjangoを習得したいと思い立ち、MacBook Airに、MacPorts, Python2.7, djangoのインストールを行いました。今まで開発はさくらインターネットから借りてるVPSにSSH接続してやっていたんですが、Pythonならローカルでも使うことがあるだろうというわけで。 パッケージ管理は楽な方法をとりたいので、まずMacPortsをインストールしました。 hide@MacBook:~/install$ curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.0.3-10.6-SnowLeopard.dmg hide@MacBook:~/install$ ls MacPorts-2.0.3-10.6-SnowLeopard.dmg Finderからこのファイルを指定するなどしてインストールすると
サーバ台数が数千台という様な大規模な環境では、サーバのセットアップや、運用を始めてからの状態の均一化にかかる工数はとても大きいため、効率良く管理する仕組みを用意しなければキッツイ状況に陥りますよね。 今まで、セットアップや、チェック用のスクリプトを作るなどして、いくらか工数を下げる事ができましたが、もっと質が良く、管理工数もかからない運用を目指し、自動構成管理ツールであるPuppetに関して調査してみました。 Puppetでできること Puppetは各ホストに付与されたルールをもとに、あるべき姿に修復してくれるツールです。 どういう状態であるか(ファイルの設置やそのパーミッション) どのパッケージがインストールされているべきか どのサービスが動作しているべきか 例えば、ある環境にRedHatとUbuntuがあり、それらにはvimがインストールされている事をルールとした場合、それを手作業で行
MySQL masterDBダウン時のサービス停止時間の短縮をはかるために、MHAについて調査してみました。 通常、運用中の大規模なサービスに、後からHAのアーキテクチャを導入する場合、多くの場合システムの再構築が発生するため、導入のコストは高くなる傾向があります。 予算を確保するため資料をつくって説明にまわり、メンテナンスの為のサービス停止許可を得るためにまた説明にまわり、サーバのセットアップ、データの移行、テスト、リリースと、コストも時間もかかる作業になります。しかしMHAは、既存の環境を入れ替えること無しに導入する事が可能なので、導入コストはとても低いです。 MHAがどういうものか、まだイメージができていない方には、この様に説明することができます。MHAは、masterDBダウン時に、手作業で行っていたslaveの昇格作業をスクリプト化し、監視処理からそのスクリプトを呼ぶことで、ダウ
楽天で開催された Cassandra Conference in Tokyo に参加してきました。多くのセッションがありましたが、楽天での採用事例が聞ける最後のセッションに参加しました。実はCassandraに関して、前提知識をほとんど持っていなかったので、自分が正しい理解をしたのか不安ではありますが、、実際に採用し得られたノウハウの紹介や、不具合をオープンソースへフィードバックしているというお話はおもしろかったです。 全体を通して思ったのは、これはCassandraに限った話ではないですが、ノウハウを持たない状態での採用はリスクが高いということです。そして、そのリスクをカバーするために以下の様に失敗の可能性を下げるための準備、失敗した時に迅速に復旧させる為の準備までも意識する必要があると思いました。 設計フェーズではCassandraを意識したクエリやスキーマにする。 テストフェーズでな
以前に Software Design の記事で見かけて気になっていたPerlを使ったwebフレームワクークの Mojolicious::Lite を使ってみました。Ruby on RailsやCake PHPなど、webフレームワークは使った事があったのですが、フレームワークの習得や環境設定に時間がかかる等、私にとってはデメリットが多かったので身に付きませんでしたが、この Mojolicious::Lite は違いました。 実際使ってみると Mojolicious::Lite の習得はごく短時間で行える事が分かりました。以下に私が書いたプログラムがありますが、プログラミングの経験がある方ならば、これを5分眺めるだけで理解出来てしまうと思います。習得の為に本を読んだりする必要はなく、いきなりコーディングに入れます。また環境設定は簡単で cpan Mojolicious だけで完了です。 M
私はアメリカのドラマや映画などが好きでDVDを購入して見ていたのですが、アメリカでは何年も前からオンラインでテレビや映画を見る事が普通になっています。 国毎にレギュレーションが異なる為、こういったサービスは「アクセス制限」や「支払い制限」を設けて、地域をもとにした利用制限がかけられています。 「アクセス制限」は、アクセス元のIPアドレスをもとにしている事が多いですが、特定のプロキシサーバからのアクセスも制限するなど、単純にサービス対象地域のIPアドレスなら何でもOKという訳ではない事が多いです。 「支払い制限」は、銀行やクレジットカードの登録地域によるものです。また海外では、PayPalによる支払いが可能になっているサービスが多いですが、このPayPalでの支払いでも同様に登録地域（≠クレジットカードの登録地域）をもとに制限がかけられている場合が多いです。 選択出来る支払い方法の何れも制限
先日インストールした rails でとりあえず hello world! 的な事をやろうとしたところ、エラーが発生したので少し調べたところ、私がインストールしたrails2.3.8は、さくらの様なCGI環境では利用出来ない事が判明しました。 もともとrailsをCGIで利用する事は、パフォーマンス面で現実的では無いという思想が rails にはあり、2.3系からCGIのサポートを辞めてしまった様です。これ以上、環境設定に時間をかけたく無かったので rails2.2.2 にバージョンを落としました。このバージョンでは、いくらかの困難がありつつも、動作が確認できました。その記録を残しておきます。 ただ、先に書いた様に、サービスで利用出来る様なパフォーマンスは出ない事が実感できました。そういう訳で、rails はモジュールとして動作させる事が出来るVPS環境を利用するのが良いと思います。Serv
さくらインターネットのレンタルサーバスタンダードで rails を使ってみたところ、パフォーマンスが非常に悪い事や、railsのバージョンアップがもう出来ない等の問題が見えてきました。(参考：Ruby on Rails on さくらインターネットのその後・・) 結局、rails を使うなら、もうVPS環境に引っ越さなければいけないので、安くて良いVPSサービスは無いかと調べ始めたところ、9月1日から、さくらインターネットでもVPSサービスを始めた事を知りました。 (参考：http://vps.sakura.ad.jp/ ） ＠IT Special PR：なぜ今さくらがVPS参入？ 田中社長に聞いた には興味深い事が書かれています。 物理サーバはQuadCore Xeon搭載機。各インスタンスには512MBのメモリと2GBのスワップを割り当てる。実は格安VPSの中にはスワップが設定されていな
このページを最初にブックマークしてみませんか？
『6pongi.wordpress.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
