私のメインマシンは未だに Mac で現在も docker を中心としたオープンソース系の DevOps 技術が大好きだ。そんな私でも正直、今年の de:code というマイクロソフトのイベントはありえない展開になっていると思う。本当にこうなったのは私の力ではなく、日米のマイクロソフトの仲間と、一緒に仕事をさせてもらっているクリエーションラインさんのおかげで、少なくとも DevOps トラックは奇跡の展開になっていると言っていい。これがマイクロソフトだからという理由で世の中にあまり知られていないのはもったいなすぎる。 OSSを愛する一人として言っておきたい。 はっきり言って、DevOps やマイクロサービスに興味があるならマイクロソフトに全く興味がない人でも参加する価値がある。 その理由を簡単にお話ししたいと思う。この先を読んでいただいたらその理由がわかってもらえると思う。 理由その１. 超
スマートフォンサイトに向けての最適化だったり、 Webページのレイアウトの変更だったりで、 同じ画像でも様々なサイズを利用することがある。 サイトの運用を続けていると、 同じ画像でも数通りのファイルを保存していて、 ファイル数が大量になってIOがキツくなってきた。 数多くなるとIO辛いから、 ファイル増やさないように気をつけてね、 と社内で言い続けていたら… Webサイトでは、本来小さい画像で良いところに 大きい画像を使用して、 JavaScriptでリサイズする処理が多用されはじめ、 今度は転送量が増加しはじめて、 これ以上増えるとデータセンターの月額費用が 増加してしまいそうに…。 なんとかせねば！と対応をはじめるわけです。 そこでまず最初にやったのが、 本当は速いImageMagick と同じように、Apacheモジュールを自作して、 ImageMagic
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 @jj1bdxさんに「このような運用論文を誰でも読める形で」「情報処理学会や信学会の論文誌掲載論文は、論文誌に掲載された後であれば、著者がWeb上で公開するのに制限はない」という情報を頂き、別に公開しない理由もないので、大規模共有型Webバーチャルホスティング基盤のセキュリティと運用技術の改善という内容で書いた論文を公開したいと思います。 僕が会社にいた時、ApacheのVirtualHost環境でレンサバを構築するというのは既にセキュリティ・運用性・パフォーマンスにおいて色々と問題がある事は10年以上前から分かっており、別の方法で共有環境を構築していました。 ある時、VirtualHostで共有環境を真面目に組むとどうなるか、という議論を元
マルウェア「Linux/Cdorked.A」はApacheだけでなくNginxやLighttpdのWebサーバにも感染を広げ、これまでに400を超すWebサーバで感染が確認されているという。 Webサーバを改ざんし、悪質サイトにリクエストをリダイレクトするマルウェア「Linux/Cdorked.A」が見つかった問題で、セキュリティ企業のESETは5月7日、このマルウェアがApacheだけでなく、NginxおよびLighttpdのWebサーバにも感染を広げていることが分かったと報告した。 Linux/Cdorked.Aは侵入先のコンピュータにバックドアを開き、脆弱性悪用ツールキットの「Blackhole」を仕掛けたWebサイトにトラフィックをリダイレクトするなどの機能を持つ。ESETによると、7日の時点で400を超すWebサーバで感染が確認され、人気の高いWebサイトがそのうちの50を占める
LTSV って何? Labeled Tab-Separated Values という、テキストのフォーマットの仕様です。CSV や TSV や JSON そのほかと同じ、テキストデータのフォーマット名。主にログ、特に httpd のアクセスログなどに適用すると便利です。 仕様は http://ltsv.org にまとまっています。随時更新中です。 LTSV は単なるログのフォーマットであって、それ以上でもそれ以下でもありません。 LTSV ってタブ区切りで値に名前を付けただけのもの? はい、そうです。 これが 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (
追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
こんにちは nakamura です。最近トルシエさんテレビ出すぎじゃありません？ウィイレヤロウヨ。オフサイドダヨ！ さてさて今回は意外と知られてないけど、サイトをインターネットに公開する際には知っておいた方が良い Apache の設定をいくつかご紹介します（一部 PHP の設定もありますが）。この設定をしていないからといって即危険にさらされるという訳でもありませんが、リスクの芽は摘んでおくに越した事はありませんよね。 無駄な HTTP ヘッダを返さない ディストリビューションにより異なるかもしれませんが、CentOS デフォルトの設定の場合 Apache が返してくる HTTP ヘッダは以下のようなものです。 HTTP/1.1 200 OK Date: Mon, 05 Jul 2010 01:01:14 GMT Server: Apache/2.2.3 (CentOS) X-Powered
Apache、PHP、MySQL、CVS、Subversionなどのサイト制作のバックエンド系のチートシートのまとめです。 各チートシートのリンクは、下記の「チートシートのポータルサイト」より収集しました。 Apacheのチートシート PHPのチートシート MySQLのチートシート CVS・Subversionのチートシート チートシートのポータルサイト Apacheのチートシート Apache 1.3 Quick Reference Card mod_rewrite Cheat Sheet htaccess Cheatsheet PHPのチートシート PHP Cheat Sheet PHP Cheat Sheet PHP 4 Quick Reference Card PHP Cheat Sheet Smarty cheat sheet PHP 4 Reference Card(PDF)
ゴール 負荷分散のいくつかの方法に関して理解する mod_proxy_balancerによる負荷分散クラスタが構築できる 基礎知識編 基本的な資料 主にクラスタによる負荷分散の資料。 - Apache モジュール mod_proxy_balancer - mod_proxy_balancerで中?大規模サーバー運用するときの勘所 - cyano あと社外秘資料。 負荷分散？ 複数台のサーバにアクセスを分散して、個々のサーバにかかる負荷を減らし、全体的に処理できるアクセスを増やすこと。 以下のようなアプローチがある。 DNSラウンドロビン DNSでひとつのホスト名に複数のIPアドレスを割り当てる方法 シンプル しかしダウンしているホストにもアクセスが振り分けされてしまう 冗長化と併用でなんとかなるかな？ 機能ごとにホストを分割 ウェブサーバとDBサーバの分割（基本過ぎるが一応これも負荷分散）
via del.icio.us/popular Apacheのフォルダローカルな設定ファイル.htaccess で使いそうな設定をかたっぱしから書き込んだファイル。 メイン、スクリプト関連、ヘッダ(キャッシュや最速化)、URL書き換え、認証、SSL、開発中サイト、というようなジャンルごとに、よく使われそうなディレクティブがずらずらと並んでいる。PHPの設定、cool URLの設定、エラーページ、認証の掛けかた、などなど。 書き換えるべきところは英単語で何を書くのかわかるようになっているので、コメントとあわせて思い出しながらコメントを外していくとそれなりに使えそうな .htaccess が作れるかもしれない。僕なんかは細かい設定方法すぐ忘れてしまって検索することが多いので、これで楽になりそう。 # 本当に不要なものはコメントにせずファイルから消すべきだし、安定運用に入ったら.htaccess
高い壁を作るだけがセキュリティ対策ではない。攻撃者の心理を考え、彼らに選ばれないシステム作りも大きな効果が望めるのではないだろうか。本連載では視点を変え、攻撃者に選ばれないためにできる、ほんのちょっとした対策を取り上げる。（編集部） 対策をもう一歩進めるための新たな視点を持とう システムは動くだけではなく、セキュリティ対策がなされていなければいけないといわれ始めて久しい。セキュリティという言葉を聞くと、物理的なものだけではなく、ネットワークセキュリティを連想するほどの認知度も得ているのではないだろうか。 個人宅のネットワーク環境にもファイアウォール機能を搭載したルータがあり、PC1台1台にアンチウイルスソフトがインストールされている。いまとなっては珍しくなく、むしろ当たり前とも思えるようになった。 一方、ネットワークに存在する脅威というと、ウイルス、ワーム、ボット、サイトの改ざん、個人情報
ウイルス、ワーム、ボットによる攻撃……ネットワーク上に存在する脅威は多種多様である。サーバにアクセスされた形跡を見て、それが通常のものなのか、それとも脅威なのかを判断するには知識と経験が必要となる。そこで本連載では、インシデント・ハンドリングのために必要な「問題を見抜く」テクニックを分野ごとに解説していく（編集部） ※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。 インシデントを最終判断するのは「人間」 インターネットは、いわずと知れた世
Web2.0としてくくられるタイプの各種ネットサービス、いわゆるウェブアプリは以前とは比較にならないほど動的生成されるものが多く、結果としてものすごい負荷をシステムにかけるわけです。 というわけで、海外におけるデジカメ画像共有サービスの代表的なものである「Flickr」の開発者がJavaScriptを高速化する手法について解説しています。 Vitamin Features >> Serving JavaScript Fast 手順を分割して簡単にしてみたり、キャッシュを使ったり、転送量を圧縮して帯域を節約したりいろいろあるようです。なお、GIGAZINEはキャッシュシステムを採用して有効活用することで負荷を現在、当初の12分の1に抑えています。 また、こっちはリバースプロキシによる高速化手法。 ViSolve.com - Squid Support Service Apacheのモジュール
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
