タグ

運用に関するatm_09_tdのブックマーク (59)

  • 完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか? まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。

    完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
  • 運用担当者、激減中

    ユーザー企業の情報システム部門で今、運用担当者の人数が大きく減り始めていることをご存じだろうか。 運用業務には、「アプリケーション保守」や「OS/ミドルウエア運用」、「ITインフラ運用」などがあるが、あらゆる業務に関わる運用担当者が減少しているのだ。まずは4社の事例を紹介しよう。 サイバーエージェント 運用担当者の人数 20人→0人(予定) サイバーエージェントで消費者向けWebサービスを手がけるアメーバ事業部では、現時点で20人いるOS/ミドルウエアの運用担当者を、2年後の2015年までにゼロにする計画だ。 彼らは現在、OS/ミドルウエアをサーバーにインストールしたり、パッチを適用したり、アプリケーションの負荷に応じてサーバー台数を増減したりする業務を行っている。これらの業務を、オープンソースソフトウエアの運用管理ツール「Chef」を導入することで、自動化する計画だ(図1)。

    運用担当者、激減中
  • PHPConference2013Presentation #phpcon2013

    PHPカンファレンス2013 11:20〜11:50 小展示ホール発表 ミッションクリティカル&ハイパフォーマンスシステムにおける技術統合と運用の勘所

    PHPConference2013Presentation #phpcon2013
  • エンジニアならウェブサーバーのひとつでも自腹で立てて運用すべき理由と、サーバー環境の選び方 : akiyan.com

    エンジニアならウェブサーバーのひとつでも自腹で立てて運用すべき理由と、サーバー環境の選び方 2013-08-26 なんかスイッチが入ったので書いてみる。 目次 技術的なレイヤーは掘り下げるべきなので、ソフトウェア・エンジニアだってサーバー運用は経験すべき ウェブ系のソフトウェアエンジニアを職業としているのであれば、ウェブサーバーのひとつやふたつは自腹で立てて、実際に運用したほうがいい。 なぜかというと、技術的な仕事にはなんでもあてはまることなんだけど、技術的なレイヤーを掘り下げることには大きな意味がある。他にもやったほうがいいことは多々あるにせよ、レイヤーの掘り下げは特に重要だ。 ウェブ系ソフトウェアエンジニアであれば、仕事で使っているサーバーや言語を支えているOSレイヤーやミドルウェアのレイヤーが、どうセットアップされて、どう管理されているのか、知っているのと知っていないのでは、ソフトウ

  • インフラチームを持たない会社でのインフラ運用

    始める DevOps ( http://atnd.org/events/41286 ) での発表資料です #init_devops

    インフラチームを持たない会社でのインフラ運用
  • Linuxサーバのディスク容量減少アラートが飛んできた!ってときにどう対処するか - たごもりすメモ

    完全に このエントリ のネタパクりです。すいません。 何に使われてるかわかったもんじゃないマシンとか開発用サーバとかだと超巨大なバイナリとか置いてあるかもしれませんが、プロダクション用のサーバでそういうことは無いとしましょう。 その場合、原因はだいたい以下のどれかです。www/appとdbが別マシンに分かれてる場合は更に絞り込めますね。 wwwサーバやappサーバ ログ 圧縮してあるが保存世代数が多くて厳しいケース 圧縮し忘れてるケース 圧縮どころかローテーションすら忘れてて1ファイルどかんと存在するケース ローテーションがうまくいかなくて deleted ファイルなケース tmpデータなど(app) キャッシュサーバのディスクキャッシュ dbサーバ データ実体 (ib_data) バイナリログ ログの場合でも、ディスク上のどこにログが書かれてるかは色々なパターンがある可能性がありますね。

    Linuxサーバのディスク容量減少アラートが飛んできた!ってときにどう対処するか - たごもりすメモ
  • サーバのリソース使用状況レポートを作る - mikedaの日記

    数百台のサーバに対して CPU メモリ HDD の使用状況をサクッとチェックしたいなーと思ったのですが、さすがにmuninのグラフで見るのはダルすぎる。 というわけで日次でこういうページを作ってチェックするようにしました。 上記の情報が数字でダーっと並んでて、ついでに簡単に色付けとか、muninへのリンク張りとか、各項目でのソート機能付けたりとかをやってます。 CPUとメモリの使用率は前日の平均、ディスク使用率はバッチ実行時の値です。 最初はmuninのRRDファイルから作ろうかと思ったのですが(gist)、この程度の情報ならsysstatやdfの結果から作るほうが簡単なので、sshで集めてくることにしました。 とりあえずHTMLに出力してますが、CSVで出したりDBに突っ込んだりすれば各種調査に便利ですよ! ソースコード Ruby1.9版です #!/usr/local/bin/ruby

    サーバのリソース使用状況レポートを作る - mikedaの日記
  • 運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた - プログラマでありたい

    ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。 状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。 Chef Server サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabri

    運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた - プログラマでありたい
  • Chefに挫折したあなたへ。Fabricのすすめ

    サーバ設定作業は面倒で間違いを犯しやすいため、Chef/Puppetなどのツールで自動化したいと考えている方は多いと思います。 私もそのような理由からChef(-solo)を習得しようと試行錯誤していました。 その結果、ある程度は動くようになったものの次のような問題があると思いました。 学習に時間がかかる 私は正直、今でもどのファイルに何を書くのかよく分かってないです。 幾分か簡単だと言われるchef-soloでも公式サイトのドキュメントだけではよく理解出来ませんでした。 また、バージョンによる差異なのか目的が異なるのか分かりませんが、ブログ記事を参考にしようとすると十人十色でどれが私に合った手順なのかわかりませんでした。 例え最終的に理解できたとしても、私やあなたが何日もかけて理解できないことはチームのメンバーも理解するのは難しいと思います。 対象サーバにインストールする必要がある Ch

  • GitとJenkinsを使ってChefを運用する(続き) - GeekFactory

    id:mi_kattun / Cookbookを完全にGitで管理するのであれば、サーバにgitやデプロイツールでCookbookをコピーしてchef-solo実行するほうがシンプルな気がするけどChef Serverを使うメリットは何なんだろう。一覧性かな http://b.hatena.ne.jp/entry/d.hatena.ne.jp/int128/20130302/1362153651 確かに! Jenkins SlaveでGitリポジトリからChefリポジトリを取得し、Chef Soloを実行する、というパターンもあります。Chef Serverが必要ない場合はこのパターンの方がシンプルです。 Chef ServerとChef Soloの比較は cloud - What are the benefits of running chef-server instead of che

    GitとJenkinsを使ってChefを運用する(続き) - GeekFactory
  • ド素人が完全自作SNSを二週間運営してみてわかったこと(後始末編、技術編、モチベーション編)

    ド素人が完全自作SNSを作ってみてわかったこと。 http://anond.hatelabo.jp/20130104184115 の元増田です。 ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、 まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。 素人のフリをしているとか、出版社のステマだとか色々言われましたが、嘘は一切書いてないです。 ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスのステマにしかなっていないような気がします…。 公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。 ~増田記事を公開してから今までの経過~ ・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。 ⇓ ・以前、完全

    ド素人が完全自作SNSを二週間運営してみてわかったこと(後始末編、技術編、モチベーション編)
  • Javaウェブオペレーションエンジニアがトラブル切りわけ時に見ていること3つ - カイワレの大冒険 Third

    忘年会シーズンで肝臓への負担を極力避けている@masudaKです。今回はJavaアプリケーションの運用のポイントに関して、書いてみたいと思います。 このエントリはJava Advent Calendar 2012の22日目のエントリです。 Javaアプリケーションの運用ポイントとは 昨今ではLLのほうが敷居が低く、開発スピードも早いということからか、PHPRubyなどのLLによるWebアプリケーションが多くリリースされているかと思います。 しかしながら、TwitterがJVMベースの開発にシフトしたように、より深いレベルで実装を行おうとした際にLL以外の実装も一つの選択肢として残っているのは間違いないでしょう。 そのようななかで自分が最もよく触れているJavaでのアプリケーションの運用ポイントについて述べてみたいと思います。 ここでいう「運用」とは、サービスをリリースしたのち、サービスへ

    Javaウェブオペレーションエンジニアがトラブル切りわけ時に見ていること3つ - カイワレの大冒険 Third
    atm_09_td
    atm_09_td 2012/12/23
    運用的な観点をまとめているのは貴重かも。
  • 「PureSystems」登場の衝撃

    システムインテグレーションにとどまらず運用のエキスパート(専門家)をもシステムに統合する──。垂直統合型システムの後発であるIBMがPureSystemsに込めた秘策は、これだ。運用負荷の増大に悩むユーザー企業のニーズに応え、ライバルに対抗するべく「現段階のベストを追求するだけでなく企業システムの次の10年を見据えて開発した」(日IBMの橋孝之会長)のである。 システム管理ソフトからのアラートを通じて異常の兆候を見抜き(インシデント管理)、原因を特定して適切な解決策を選び(問題管理)、システムリソースの追加など障害対策を実施する(変更管理)。システムの維持管理で最も重要なこれらのプロセスを、PureSystemsでは、非機能要件などを定義した「パターン」を組み込んだ運用管理ソフトによって遂行する。IBMが提唱してきたオートノミック・コンピューティング(自律型コンピューティング)のコンセ

    「PureSystems」登場の衝撃
  • [JavaScript] Jenkinsの対抗馬になるか?ビルド管理をJSで行うGrunt.jsの内容説明とスタートアップ - YoheiM .NET

    [JavaScript] Jenkinsの対抗馬になるか?ビルド管理をJSで行うGrunt.jsの内容説明とスタートアップ こんにちは、ビルド管理といえばJenkinsだと思っていた@yoheiMuneです。 最近、node.js上で動くJavaScriptのビルド管理ツール「Grunt.js」について学んだので、今日は簡単な説明と 「Hello World」的なところまで書きたいと思います。 Grunt.jsとは何? grunt.jsは、grunt@Githubで公開されている ビルド管理ツールです。 個人的には、Jenkinsがビルド管理ツールとして有力だったのですが、 grunt.jsではフロントエンドのビルド作業を楽にできるいい感じのツールです。 Jenkinsでは例えば以下のようなビルドを行うと思います(JavaのWebアプリケーションの場合)。 checkStyleやfingB

    [JavaScript] Jenkinsの対抗馬になるか?ビルド管理をJSで行うGrunt.jsの内容説明とスタートアップ - YoheiM .NET
  • 定期実行スクリプトの綺麗なロギング3選 - カイワレの大冒険 Third

    オリンピックの流れに乗れてない@masudaKです。 職業柄かちょくちょくスクリプトを書くことはあるのですが、やはり色々自分で書いたり人のを見たりしてるうちに、この実行履歴綺麗だなーと思うことが多々あります。 今回は、そう思える対象のなかでも、「定期実行スクリプト」の「出力」を扱ってみたいと思います。 「定期実行スクリプト」というのは、バッチ処理だったり、何か必要に応じて叩かれるスクリプトで、具体的にはバックアップとか集計とか、一日に最低一回は叩かれるようなスクリプトです。cronやJenkinsで叩かれるような類ですかね。そのようなスクリプトの「出力」について書いてみたいと思います。 出力は標準出力であれば、tailfコマンドだったり、Jenkinsのビルドのコンソール出力で見られるようなもの。ロギングされてるのであれば、それと同様に追えるようなものとします。 以下に書くのはあくまで今の

    定期実行スクリプトの綺麗なロギング3選 - カイワレの大冒険 Third
  • サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開

    サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 米国でビデオオンデマンドサービスを提供しているNetflixは、Amazonクラウド上でわざとシステム障害を起こすためのツール、Chaos Monkeyをオープンソースで公開しました。 Chaos MonkeyはAmazonクラウド上で使うツール。Amazonクラウド上のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。 NetflixはこのChaos Monkeyを実環境で使うことで、物の障害が起きたとしてもサービスが継続できることをテストし続けてきました。Netflixのブログ「Chaos Monkey released into the wild」から引用します。 There are many fail

    サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
  • “障害発生前の解決”をどうやって実現するか

    データセンター環境で“監視”といえば、まず思い浮かぶのは「死活監視」だろう。文字通り、サーバが「生きている(稼働している)か、死んでいる(停止している)か」を見極める簡便な手法だ。 これだけで用が足りる場合ももちろんあるが、それだけでは複雑化する現在のシステム構成には対応しきれないという課題が明らかになってきている。 今回は、死活監視の限界と、これから欠かせない存在となるサーバ性能監視のポイントについて考える。 死活監視の限界 物理サーバの処理能力を無駄なく使うには 死活監視は、端的に言ってしまえば「1サーバ、1アプリケーション」構成を前提とした、ごく簡便な監視手法である。 Webサーバでは、現在でも1Uラックマウントサーバをラック一杯に詰め込み、それぞれのサーバでは必要最小限の構成のOSとWebサーバ・ソフトウェアだけが稼働している、といったシステムが使われるが、こうした使い方なら、死活

  • 1台から500台までのMySQL運用 MySQL Beginners

    5. On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Our Service (livedoor) Amazon MechanicalAmazon Mechanical Turk Mechanical Turk Amazon Mechanical Turk Mechanical Turk Turk Amazon Amazon t/ Workers Workers Requester Requester On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Amazon MechanicalAmazon

    1台から500台までのMySQL運用 MySQL Beginners
  • お金を(なるべく)かけずにサーバー運用出来るか試してみた | popowa

    最初に結論 [ドメイン周りをスムーズに扱えるPaaSは売れる!] ドメイン popowa.comに付随する過去のサブドメイン遺産をどれだけ安く運営出来るか試してみました。 過去のサブドメイン遺産はほとんどアクセスがない、もしくは自分しか使っていないのでここではスケールが出来るかどうかは重要視しない事にします。 このドメイン(popowa.com)には、 ネームサーバ メールサーバ ブログサーバ レポジトリサーバ ウェブサーバ 検証で試したOSSなアプリ(主にWordpressなど)用検証サーバ がありました。 過去使っていた有償環境としては 自宅サーバー さくらVPS ムームードメイン Lolipop AWS VPSLink Tektonic Xrea RackSpace とかで運営していました(順不同)。 ■ネームサーバー まずネームサーバーをAWSが提供しているRoute 53に移しま

  • Webアプリのパフォーマンスアップ作戦 - ゆーすけべー日記

    予定している機能を実現するアプリが完成するだけでWebサービスが成り立つわけではありません。 運用の最中にパフォーマンスにまつわる問題が出てくる可能性があります。 それは突然大きなトラフィックがやってきたというような時だけではありません。 知識が無いうちですと、いざ運用に乗せてみるとずいぶんとサイトの読み込みが遅いといったケースが発生することもあります。 僕はいくつかのエロサイトを管理しているのですが、 その中に月間700万PVのアクセスをいただいている「サイトA」があります。 サイトAの場合、トラフィックもそこまで無かった当初からパフォーマンスに関する問題がいくつか発生し、 その都度調べては実践で試して対策をしてきました。また、できる限り少ないリソースでの運用を目指しています。 今回はWebアプリのパーフォマンスアップ作戦として、 サイトAでの運用経験からのいくつかの方針やTipsを紹介

    Webアプリのパフォーマンスアップ作戦 - ゆーすけべー日記