現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か
イメージベースのデプロイについて（あるいはIaaSだとこんなんが良いんじゃないと言う意見） - ローファイ日記
最近、仕事やら趣味やらで AWS / OpenStack / GCE その他のいわゆるIaaSなプラットフォームを調査したり、いじったり、そのAPIをいじったりする機会が多かった。 この辺の運用を考えていて試したこと、ぶつかったことなどをまとめたい。 実際やったこととしては、特定のプラットフォームに依存している訳ではないが、たいていの人はAWSのアレね、みたいなイメージを持った方が読み進めやすいんじゃないかと思う。 ゴールデンイメージを雑に走らせること この手のIaaSの基本であるが、サーバーはインスタンスと呼ばれ、イメージを指定して起動する。ec2 aws run-instanceとかnova bootとかその類いである。 イメージからの起動のためには雑には大きく2要素があって、一つはイメージ自体の構築、もう一つは起動直後のそれぞれのインスタンスの特性に合わせた初期化処理のフェーズである
serverspec インフラ層のテスト項目を考える | Ore no homepage
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
YAPC::Asia 2013ではてなのサーバ管理ツールの話のはなしをしました - ゆううきブログ
YAPC::Asia 2013で"はてなのサーバ管理ツールの話"というはなしをします - ゆううきブログ YAPC::Asia Tokyo 2013で、アルバイトで開発してたサーバ管理ツールのはなしをしました。 前半がサーバ管理ツールの開発思想で、後半がサーバメトリクス可視化の実装についてです。 キワモノツールであるRRDtoolの話は後ろに押し込んであるので、興味ない方は最初のほうだけ見てもらえればよいと思います。 感想 トーク後に結構話しかけられたりしてうれしかった。 トークの内容をブログに書いて、インターネット上で何か反響を得たことはあったけど、トークしたその後、直接話しかけられることは今まであまりなかった気がする。 コミュニティで認められるのに何か発表するのって大事だなと改めて思った。 RRDtoolをご存知の方が会場内でパッとみで1/4くらいいらっしゃったので、結構インフラ系の人
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
Image and Video Upload, Storage, Optimization and CDN
Image and Video API for Powerful Visual Experiences Store, transform, optimize, and deliver all your media assets with easy-to-use APIs, widgets, or user interface. LEARN MORE → AI-Powered Image & Video Transformation at Scale Transform your image and video workflows with Cloudinary’s Generative, LLM, and Content-Aware AI features. LEARN MORE → TRY OUR GENERATIVE AI DEMOS → Create, manage, and del
ファイル/ディレクトリの変更を検知してコマンドを実行するincron - Glide Note
incron :: inotify cron system webistranoでファイルをデプロイして、設定の再読み込みやサービス再起動などが必要な際に、 デプロイユーザがsudoでreloadやらrestartなどを実行しているのが、 権限的に何となく気になって、ファイルの更新を検知して 自動的にreloadやrestartする方法を模索していたら incronという良い物があったので検証。 検証環境はScientific Linux 6.2です。 実現したいこと デプロイユーザとサービス再起動ユーザの分離(sudo権限の剥奪) Nagiosの設定ファイルをデプロイしたら、Nagiosのreloadが自動でかかる Passengerのrestart.txt的な感じでreload.txtがトリガーでNagiosのreload的な incronの導入 incronをyumで導入
Amazonがクラウドに関する「都市伝説」に反論、「AWSの真実」とは？
Amazonによると「クラウドより既存のデータセンターやプライベートLANの方が安全である」「高信頼度・耐障害性ということを考えるとクラウドは使えない」「クラウドに基幹の業務システムは乗せられない」という言説は「都市伝説」だと考えているとのこと。つまり、正しくない、と。 これは「次世代ディザスタリカバリを成功させるアマゾンクラウド活用法」ということで、東京国際フォーラムで開催された「Cloud Computing World Tokyo 2011」＆「Next Generation Data Center 2011」において講演されたもので、Amazon EC2をはじめとするAWSについてのプロモーションも兼ねており、非常に参考となる内容になっています。 以下がその講演を再現したものです。 人だらけ ぞろぞろ あのAmazonの講演なので出席率がこれまた異様に高い アナウンス「『次世代ディ
大規模インフラの監視システム その2 | GREE Engineering
こんにちは。グリーのmdoi(@m_doi)です。 今回は、グリーの監視システムについて説明したいと思います。以前、こちらの記事にて、リソース監視システムの説明をさせて頂きましたが、死活監視やログ監視については語られなかったので、気になっていた方も多いと思います。ということで、今回は、グリーのインフラにおける死活監視やログ監視、アラート通知システムを紹介したいと思います。 何を使っているの？ グリーでは、死活監視にNagiosを使用していました。監視システムの中では、かなり有名なソフトウェアですから、監視システムの構築に使用したことがある方も多いのではないでしょうか。プラグインも豊富に存在するので、様々な監視を行うことができます。死活監視は、このNagiosの機能をそのまま利用し、ログ監視は、Nagiosと独自に作成したエージェント及びログフィルタを連携させて行っていました。 全体のシステ
大規模インフラの監視システム | GREE Engineers' Blog
こんにちは。インフラチームの ebisawa です。 今回はグリーのインフラにおける各種機器の監視がどのように行われているのかご紹介させていただきたいと思います。一般にサーバの監視というと、システムダウンを検出するための死活監視を意味する場合と、ネットワークトラフィック等のモニタリングのことを意味する場合とがあります。今回の監視は特に後者についてのお話です。大規模なインフラの監視には、やはり特有の課題があります。 どんなツールを使っているのか グリーではサーバの各種リソース使用状況をモニタリングしてグラフ化するためのツールとして、Cacti を利用しています。Cacti は、大変有名なツールなので皆様ご存知かと思いますが、バックエンドの RRDtool で作成したグラフを閲覧するための使いやすいユーザーインターフェイスを備えています。 http://www.cacti.net/ ツールの使
これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」
Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
自宅サーバのインフラ設計書を公開します - @int128
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog
エンターテイメント業界におけるAWS活用事例
Twitterにおける大規模システム構築、3つの原則
省サーバ運用