ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
Webサーバのログをリアルタイムで解析、監視できる『GoAccess』コマンド | 俺的備忘録 〜なんかいろいろ〜
今回は、Webサーバのログ解析をリアルタイムで行えるコマンド『GoAccess』を紹介する。 1.インストール まずはコマンドのインストールから。 以下のコマンドを実行する。 ソースコードからmakeする場合 wget http://tar.goaccess.io/goaccess-0.8.5.tar.gz tar -xzvf goaccess-0.8.5.tar.gz cd goaccess-0.8.5/ ./configure --enable-geoip --enable-utf8 make sudo make install パッケージ管理ソフトからインストールする場合 brew install goaccess (Mac OS Xの場合) sudo apt-get install goaccess (Debian/Ubuntuの場合) sudo yum install goacc
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
実行中のアプリケーションを外から観察するコマンド。 - こせきの技術日記
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
digitalOceanクラウド上に安く簡単にkippoハニーポットを構築する
ozumaさんの公開された抱腹絶倒のスライド資料「さくらのVPSに来る悪い人を観察する その２」が凄い人気で、ブクマコメントなどで「ぼくもやってみたい」という希望が多いようです。既に、同じozumaさんが「sshハニーポットをkippoで作ってみる」というエントリで作り方（CentOS6.4想定）を公開されていますが、pythonのモジュールのセットアップなど少し難しいという人がいるかもしれません。 それ、digitalOcean + Ubuntuならもっと簡単に安く（しかも安全に）できるよ ということで、簡単・安い・安全な kippoハニーポットの作り方を説明します。digitalOceanは一時間約1円の完全従量制なので、お財布も安心ですw digitanOceanのアカウントを作成する こちらを参考にdigitalOceanのアカウントをご用意ください。こちらのリンクからアカウントを
今さら聞けない Immutable Infrastructure - 昼メシ物語
Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
AWS re:Invent と Immutable Infrastructure - 昼メシ物語
先日 Las Vegas で開催された AWS re:Invent 2013 に参加してきました。 非常に活気あふれる大規模なカンファレンスで、大変刺激を受けました。 今日は、いま何かと話題になっている Immutable Infrastructure に関連した発表を2つ紹介します。 Stop Worrying about Prodweb001 and Start Loving i-98fb9856 slideshare: Stop Worrying about Prodweb001 and Start Loving i-98fb9856 (ARC201) | AWS re:Invent 2013 AWS の Chris Munns 氏による発表です。タイトルからして面白いですね。エモいです。 この発表は以前から目をつけていたんですが、スケジュールの都合で出られず、残念でした。こうしてス
Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowler
As a developer and sometimes system administrator, one of the scariest things I ever encounter is a server that’s been running for ages which has seen multiple upgrades of system and application software. Why? Because an old system inevitably grows warts. They start as one-time hacks during outages. A quick edit to a config file saves the day. “We’ll put it back into Chef later,” we say, as we fin
Webサーバのメンテナンス、トラブル調査に役に立つコマンド3選 - Glide Note
メンテナンス、サーバのミドルウェア設定、障害対応のときに私がよく使っているコマンド。 先週Webサーバを16台ほどリプレイスした際にも、使って挙動、確認作業をしてました。 コレ系のコマンドは各人の秘伝のタレみたいになってて、他の人が教えてくれることが少ない気がして、 新卒氏のインフラOJT用に専用の資料作ろうかと思ったけど、新卒氏以外でも知ってれば 「よく分からんけど、動かないからインフラ担当者に聞く」みたいなことが 減って自分で解決出来るのではないかと思うので書いておく。 手元のmac、linuxから該当サーバに対して実行するコマンドで ちゃんと該当サーバが外部に向けてサービスが提供出来ているのか、 要は外から確認するためのコマンドです。 調査系のコマンドは オプション、使い方が覚えやすい 手軽に使える 結果が見やすい、理解しやすい というのが重要だと思う。 サーバの中で調査するなら 原
Linux系インフラエンジニア3年目のスキルを見抜く50の質問（ホスティングの場合）
数年前になんとなく面白がって書いてた「Linux系インフラエンジニア3年目のスキルを見抜く50の質問（ホスティングの場合）」というのが、昔の資料をあさってると出てきて、意外と面白かったので少しだけ手を加えて（古い情報とかあったので）公開しようと思います。 意外とリアルなものがあって懐かしい気分になりました。過去に書いた以下の記事もどうぞ参考にして下さい。 「Linuxエンジニアを目指して入社一年目にやって役にたったと思う事」 「Linuxエンジニアを辞めて大学院に入学しました」 追記： 設問1があまりによくないので、@tagomorisさんのアドバイスを頂きつつ変更しました。1を消して3を追加しています。ありがとうございます！ 2000台以上のサーバー運用経験はありますか？ サーバやネットワーク機器のキッティング経験はありますか？ サーバやネットワーク機器の交換を現地のデータセンター職員に
Immutable Infrastracture について - aptheia.info
ここ最近話題に上がることが多い Immutable Infrastracture と、その他仮想環境周りについての雑感。 Immutable Server や Immutable Infrastracture っていう単語がいろんなところで目に入るようになった。とくに Chad Fowler がブログで取り上げたり、Food Fight に出たり して、世間でも関心が高まった感じがある。 プログラムを書く人にはご存じの通り、この Immutable っていうのは状態が変更出来ないことを指している。Immutable な Infrastracture っていうのは、ざっくり言うと「運用中のサーバーに変更を加えない」っていうアプローチでサーバーを管理しているスタイルのこと。 (ファイルシステムを読み取り専用にする、とかそういう話じゃなくて、あくまでそういう方針でやろうっていう話) サーバーの設
完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
slaveの負荷分散＆フェイルオーバー(HAProxy)
前回はmysql-proxyによるslaveの負荷分散でしたが、 今回はHAProxyによる負荷分散＆フェイルオーバーを行いたいと思います ・HAProxyとは 一部抜粋 http://dexlab.net/pukiwiki/index.php?Memo%2FLinux%2Fhaproxy L7ロードバランサ。アプリケーション層のHTTPやSMTP等が対象。 対するL4ロードバランサはネットワーク層のTCP/UDP等が対象 メリット DB Slave, memcacheノード追加/変更/削除時にアプリケーション側を変更しなくて良い。常にローカル(127.0.0.1:xxxx)へアクセスすれば良い 負荷分散/フェイルオーバー機能を担保してくれるため、アプリ側で実装しなくて良い 上記ノード変更時にサービス停止の可能性が減る 負荷分散/フェイルオーバー機能を持たないソフトでも利用できる場合がある
サーバやPCのボトルネック箇所の簡単な見分け方(Linux編)：佐野裕のサーバ管理者日記：ITpro
前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コマンドによる「負荷」の原因切り分け
さくらのVPSに来る悪い人を観察する その２