少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ！絶対！ rootを常用するの(・A・)ｲｸﾅｲ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに

現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。 そこで今回は、先述した私たちのデ

こんにちは！@at_grandpa です。 この記事はVOYAGE GROUP エンジニアブログ : Advent Calendar 2013の19日目の記事になります。 今年ももうあと10日前後となりました。みなさんいかがお過ごしでしょうか。 さて、何を書こうかな エンジニアの Advent Calendar 界隈では、「年末年始を安心して過ごすように」系記事も多数投稿されていますね。 私もそれ系を書こうと思いましたが、インフラはド素人なのでどうしたものかと。 で、以下の本を読んだ時にテーマが決まりました。 [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メ

大きな効果を上げるために チューニンガソン#1～#3の改善率を見ると、アプリケーションや全体のアーキテクチャに手を入れないで改善できるのは最大でも10倍以下です。もちろん数倍速度が違えばサーバ台数を大きく減らせるので有意義なのは間違いないのですが、ISUCONやチューニンガソン#4のような飛躍的な高速化は望めないことがわかります。 つまりチューニングでは、単にパラメータ設定を変更するのみではなく、ボトルネックになっているコードやクエリ、アーキテクチャに的確に手を入れていくことで大きな効果を上げることができるのです。 ボトルネックの発見と解消が大事 システム全体の処理時間についてパレートの法則（経験則）を適用すると、「⁠全体の処理時間の80％は20％の部分で発生している」ということになります。実際にシステム全体で一番ボトルネックになっている部分を解消しないことには、ほかの部分に手を入れても大

こんにちは！ 先月ドワンゴは歌舞伎座に引っ越しましたが、 "銀座"に着てく服がなくて毎日困ってる氏家と申します。 インフラエンジニアとしては新参者になるのですが、よろしくお願いいたします。 ドワンゴの中ではniconico系の事業を担当しているのですが、 2006年にニコニコ動画がスタートしてもう少しで7年になろうとしています。 昔からあるシステムはサーバー構築手順も確立されてるのですが、 新しめのプロジェクトではChefを導入してサーバー構築をしようとしています。 先日の参院選で、ニコ動アンケートが97.52%の的中率というニュースをご覧になられた 方もいるかと思いますが、あのアンケートシステムもChef Soloを使って構築しました。 大規模なシステムはChef Serverで構築してるところもあるのですが、 今回私が解説するのは、比較的小規模な構築に向いているChef Soloの話に

以前から「誰か書いてくれませんかね」とか言っていた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」ですが、誰も書いてくれないので自分で書きました。 本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 現状、合計で140行くらいのJavaプログラムで、普通に画像やCSSを含むWebページが表示できています。こちらのページの下のほうにも画像を貼っていますが、こんな感じで、ローカルのファイルシステムに置いてある私のWebサイトのトップページが表示できていますし、もちろんリンクをクリックして遷移することもできます。 「えっ? Webサーバってこんなに簡単に書けるの?」と思う人も多いのではないでしょうか。 もちろんこんなのは「わかっている人」から

.zshrcにstatic_httpdって関数つくってる。 dotfiles/.zshrc at master · kamipo/dotfiles · GitHub function static_httpd { if type plackup > /dev/null; then plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root => ".")->to_app' elif type ruby > /dev/null; then if ruby -v | grep -qm1 'ruby 2\.'; then ruby -run -e httpd -- --port=5000 . else ruby -rwebrick -e 'WEBrick::HTTPServer.new(:Port => 5000, :D

第1回のアジェンダ編では、高速化に関わる要因と解決策の全体像を紹介しました。 アジェンダ編にもかかわらず多くのブックマーク、シェアをいただきありがとうございます！ 余談ですが、記事にブックマーク、シェアをしていただくと、このブログでは執筆者に経験値がたまるような仕組みになっています。 たくさん経験値を貯めると四半期ごとに良いことがあるかもしれないので、気が向いたらこの他の執筆者の記事もシェアしていただけるとうれしいです。 言葉にせずとも、わかっていただけると思いますが、この記事も・・・ね？ 右上にあるボタンをちょちょっと。 本題 余談はさておき、本題に入りましょう。 今回は「無駄なリクエストとレスポンスの削減」に視点を置き、解決策について調査、計測して紹介してみたいと思います。 と思ったのですが、長くなりすぎたため、まずは「検証ツールとHTTPについて」紹介することにしました。 この記事の

さくらのVPSのリニューアルが発表された。 メモリやHDD容量がかなり強化されていて、HerokuなどのPaaSや、さくらのクラウド・AmazonなどのIaaSに流れていった人もさくらのVPSに戻ってきそうな勢いらしい。 4/20まで乗換キャンペーンもやっているようなので早速新しいVPSに引越してみた。 せっかくなので、GitLab + Unicorn + Nginxで最新のバージョン管理環境を作ってみようかと。 GitLabとは、プライベートなGitHubを目指したOSSで、GitHubでホスティングされている。 GitLab - Self Hosted Git Management GitHubの無料アカウントではパブリックなリポジトリしか持てないので、仲間内でこそこそ開発してる人とか、スタートアップでお金があまりない時期の人とか、みんなに見せるほどでもないものを管理したりするのにはG

下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で

#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :

軽快なscpか高機能なsftp、sshサーバに向いているのは？：セキュリティプロトコルマスター（8）（1/2 ページ） 前回はsshを使って安全にサーバを管理する方法を取り上げました。実はこのsshにはちょっとした仕掛けが隠されています。そんな仕掛けを上手に使う「安全なファイル転送」を今回取り上げましょう。安全なファイル転送は、サーバ管理だけでなく、さまざまな場面で活躍するはずです。 安全なファイル転送とは 安全なファイル転送って何ですか？ ファイル転送とは、ネットワークでつながったコンピュータにファイルを送ったり、受け取ったりすることです。つまり、ファイル転送をするには、ネットワークの中をファイル本体が流れていく、ことになります。 ここで問題になるのが、盗聴、改ざん、なりすましの問題です。第三者に知られることなく、ファイルの内容そのままで、正しい相手に送り届けるためには、単に相手へファイ

2つのRailsアプリにリバースプロキシを使ってそれぞれ振り分ける例。 ディレクトリベースで振り分ける例 user nginx; worker_processes 4; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 1024; } http { # Railsアプリの静的コンテンツはmongrel_clusterだと遅いのでもっと高速なサーバで upstream static { server 192.168.0.12:80; server 192.168.0.13:80; } # Railsアプリ mongrel_cluster upstream app1 { server 192.168.0.12:3000; server 192.168.0.12:3001