先日「サーバーのセキュリティ設定がなにすればいいかわからない」と相談をうけまして。 自分も初心者の時どこまでやればいいかわからず手当たりしだいにやって沼に入っていたのを思い出しながら自鯖構築したときのメモを元にまとめてみました。 注意 セキュリティ対策は用途や場合などによって違います。 自分で理解したうえで自己責任でおねがいします。 対象読者 Linuxのサーバーを建て慣れていない人 Linuxはある程度さわれる人(自分でパッケージを入れたり、サービスを止めたりできる) ラインナップ ☆は導入の重要度と導入の容易さから個人的偏見からつけた値です。 4つ以上が"最低限やること"だと思ってください。 sshd
まずは遅くなる原因を取り除こう この記事ではクライアントサイドに焦点を当てて紹介しますので、PHP や Ruby などサーバーサイドのプログラミングに関することは一切出てきませんのでご了承ください(o*。_。)oペコッ サイトの読み込みが遅い場合、大抵はまずいやり方をしている一部分が足を引っ張っていることが多いと思います。 手当たり次第に最適化を試す前に「なぜ遅いのか?」問題の切り分けをしっかりやってから対応を考えましょう。 原因はどうやって特定するの? PageSpeed Insights (developers.google.com) を使ってみる ブラウザ搭載のデバッガで調査するのが王道だけど、お手軽に調べるのであれば PageSpeed Insights がキャッチーでオススメです。 最低限のお作法について指摘してくれるので、指摘事項を直していけば割と解決します。(原因が曖昧なま
Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
2015年1月27日(現地時間) Qualysはglibc(GNU C Library)に脆弱性を発見し、情報を公開しました。ここでは関連情報をまとめます。(暫定まとめなので精度低め、網羅性無しです。。) (1) 脆弱性関連情報 Qualysが公開した脆弱性情報 The GHOST Vulnerability Qualys Security Advisory CVE-2015-0235 注意喚起 IPA (注意) libc の脆弱性対策について(CVE-2015-0235) 脆弱性の概要 glibcの__nss_hostname_digits_dots() にヒープバッファオーバーフローの脆弱性。 当該関数はglibcのgethostbyname()とgethostbyname2()から呼ばれている。 アプリケーションによっては、DoS、またはリモートから任意のコードが実行可能となる可能性
NECは、アンゴラとブラジルを結ぶ大容量光海底ケーブル敷設プロジェクト「SACS(South Atlantic Cable System、サックス)」の建設請負契約をアンゴラケーブルズ社(Angola Cables, SA、注1)と締結しました。本海底ケーブルの稼働開始時期は2016年末の予定です。 「SACS」は、アフリカ大陸と南米大陸間を結ぶ南大西洋を横断する世界初の光海底ケーブルシステムであり、NECにとっても大西洋で初めて手掛けるプロジェクトです。本海底ケーブルは、アンゴラのサンガノ(Sangano)とブラジルのフォルタレザ(Fortaleza)を結ぶ、総延長約6,200kmの光海底ケーブルです。また、一波長あたり毎秒100ギガビット(100Gbps)となる最新の光波長多重伝送方式に対応し、建設時設計容量として毎秒40テラビット(40Tbps、注2)の伝送が可能です。 NECは、今
本日βテストが始まった はてな の新サービス Mackerel を試してみました。 Mackerel はサーバのステータスを管理・監視するための SaaS です。 CPU使用率などの情報をサーバに仕込んだエージェントが Mackerel のサーバに送信し Mackerel 側でそれを取りまとめてグラフ化してくれたりするサービスです。 これがダッシュボードです。 すでに Kindleコミックデータベース のサーバを設定した状態になっています。 モダンな感じでいいですね。 設定手順を振り返ってみます。あまりのチョロさに説明も不要かもしれませんが。 1. アカウントを登録する まずは「無料アカウントを作成」をクリックして Mackerel に登録します。 はてなのサービスですが はてなID は使えません。新しくアカウントを登録しましょう。 メールアドレスを入力するだけで登録は完了します。 ログイ
CoreOS は Alex Polvi が設立した会社であり、OS、新しい Linux Distribution である。OSS で公開されている。 Polvi 氏といえば Rackspace に 買収された CloudKick を立ち上げ、その後も Rackspace 働いていたクラウドの専門家とも言えるだろう。 その Polvi 氏以外にも Googler や Linux 関連の人材、アドバイザーに Linux の stable branch のメンテナ を迎えるなど、Linux に関する知識がかなり豊富なメンバーが集まっている。 その彼らが作っているのが CoreOS である。 CoreOS は Google や Facebook などの環境を参考にしており、柔軟にスケールし、さらにはインフラ構築その もののプロセス自体も効率よく合理的に行えるよう設計されている。 また運用、管理(セ
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツール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
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
IIS のインストール、PHP のインストールと設定、認証の設定など、IIS を動かすまでについてはこちらに記載しています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く