タグ

インフラに関するmuto_masaのブックマーク (7)

  • Linuxサーバのディスク容量減少アラートが飛んできた!ってときにどう対処するか - たごもりすメモ

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

    Linuxサーバのディスク容量減少アラートが飛んできた!ってときにどう対処するか - たごもりすメモ
    muto_masa
    muto_masa 2013/07/30
    あるある。
  • スタートアップ企業向けインフラ運用入門(4):システム拡張の具体例

    システムをリリースして無事運用に乗った後も、様々な要因によりシステムを拡張する必要が出てきます。今回は、システム拡張の要因、及び基的なシステム拡張の方法を具体例を挙げつつ説明していきます。 初めに これまで4回に渡り、インフラ運用に関する入門的な記事を書いてきました。それらの内容を実施して、システムが安定運用に乗ってきたと仮定します。業務系のシステムであれば、そこでインフラ担当の仕事は大体終わりとなり、オペレーターなどに主要な業務を引き継ぐことになると思います。それに対してRettyのようなWebサービスの場合は、システムが軌道に乗った後も継続的なシステム拡張が発生することが一般的です。 記事では、まずどのような事をきっかけ・要因としてシステム拡張が必要になるのかについて説明します。次に、Rettyのシステム構成を簡単に説明し、システム拡張が必要となる各種要因に対して、どのような方針で

    スタートアップ企業向けインフラ運用入門(4):システム拡張の具体例
  • Automation Tech Casual Talks #1で発表してきた。 : インフラエンジニアに成る

    Puppet使って構成管理を自動化したときにDevOps意識したよーな内容。 さて、おもったより#autotechcasualでつぶやきまくっていたので思い出しながら以下、つらつらと。 第2回開催時の参考になればと思います。 先にまとめ。 ・インフラ視点の話が中心 ・ChefとPuppet使っているけどどうなの?な話 ・Jenkinsチラチラ ・AWS使っているお話ちらほら ・DevOpsの意識 このあたりに興味あるかたには非常に意味のある集まりになったかと思います。 僕は楽しかったな〜。 ※ 資料はアップに気づいたら随時追加しております。 ■@n0tsさん 主催者が先頭きって発表。 「ぼくがかんがえたさいきょうの☆きっくすたーと☆」はたしかに最強だった。 cobblerのkickstartでどこまでできるかがテーマ。 githubにまとめてあげているのがすばらしい。 ただ、3年ほど使用し

    Automation Tech Casual Talks #1で発表してきた。 : インフラエンジニアに成る
  • 『サーバの構築作業やシステム管理を自動化する「Chef」』

    皆様、はじめまして。2010年9月に入社した並河です。 インフラ周りの話題を・・・ということで、今回はサーバの構築やシステム管理作業を楽にしてくれるツールである「Chef」について紹介します。 ■ Chefとは「Chef」は、サーバOSでのインストール・設定・各サービスの状態管理等、諸々のシステム構築や運用作業を自動化してくれるRuby製のシステム管理ツールで、オープンソースとして公開されており、既に、37signalsやEngine Yard、RightScaleなどでも使われており、利用実績も出始めています。 Ruby製のシステム管理ツールといえば「Puppet」を思い浮かべる方も多いのではないでしょうか。ChefはPuppetの競合ソフトウェアとなる位置付けで、出来ることだけでいうと、特別大きな差はないと感じていますが、Puppetは外部DSLとして設定を記載するのに対し、Chefは

    『サーバの構築作業やシステム管理を自動化する「Chef」』
  • グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering

    はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる

    グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
  • るびま

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

  • 第11回 [キャリアアップ編③]varnishを使おう | gihyo.jp

    これらを必要に応じて書き換えることができます。たとえば、番サービスなどで利用する場合、特にDMZセグメントで構成しようと考えるのであれば、-Tの管理画面待ち受けポートは変更するなどした方が良いでしょう。 また、サービスの規模に応じて、-sのキャッシュファイルの場所や容量を変更することになるかと思います。デフォルトでは、/var/lib/varnish/varnish_storage.bin に1Gバイトの容量を確保しますが、大規模コンテンツ、高トラフィックでキャッシュサーバ自体もかなりの台数並べるようなサービスであれば、このデバイス自体をメモリ上にやSSD、f-ioなどの高速デバイスにするかを検討します。 varnishとApacheを別々のサーバに入れてみる さて、1つの筐体にvarnishとApacheを入れ、稼働を確認することができたなら、次は同居していたApacheを別筐体へ移動

    第11回 [キャリアアップ編③]varnishを使おう | gihyo.jp
  • 1