Apache Kafkaを用いたリアルタイムデータ処理の商用サービスを提供しているConfluentは、Apache Kafkaに対応したオープンソースのSQLエンジン「KSQL」のデベロッパープレビューをリリースしました。 Apache Kafkaはスケーラビリティに優れ、大量のデータをリアルタイムに処理できるソフトウェアです。さまざまなアプリケーションから送られてくるログや大量のセンサーなどから生成されるデータなど、リアルタイムに送信されてくるストリームデータをいったんKafkaで受け止め、それをまとめてHadoopなどの分析エンジンに渡してデータの分析を行う、といった形で使われます。 KSQLは、このKafkaに対応したSQLエンジン。これによりJavaやPythonで複雑な処理を記述しなくとも、ストリームデータを柔軟に加工できるようになります。 SQLとKSQLの違いとは？ 一般的
This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their core components. It then provides a table comparing 8 popular open source messaging platforms: Apache Kafka, ActiveMQ, RabbitMQ, NATS, NSQ, Redis, ZeroMQ, and Nanomsg. The document discusses using Apache Kafka for streaming and integration with Google Pub/Sub, Dataflow, and BigQuery
外部から簡単にHTTP_PROXYという環境変数がセットでき、サーバ間通信や外部サイトと連携している場合に影響があるかもしれない脆弱性です。(HTTPoxy. CVE-2016-5385) PHPの場合はphp-fpm, mod_php, Guzzle4以上やいくつかのライブラリで影響あります。 対応方法は簡単です。 Apache側で対応する場合は、mod_headerを使える状況であれば、confファイルに下記の1行を追加。 RequestHeader unset Proxy FastCGIの場合は下記の1行を追加。 fastcgi_param HTTP_PROXY ""; Guzzleは6.2.1で対応されたようです。 Release 6.2.1 release · guzzle/guzzle · GitHub コミットログを見ると、CLIの時のみ、getenv('HTTP_PROXY
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
こんにちは。インフラチーム Hazama の深谷です。 デブサミ 2015 で、cybozu.com の自社製リバースプロキシを全面的に再実装した話をしてきました。 今回は、そちらの資料を紹介いたします。 cybozu.com ではお客様ごとに異なるサブドメイン（ex. demo.cybozu.com）を用意しています。サブドメイン方式には、お客様ごとに異なる IP アドレス制限をかけられるとか、Same-Origin-Policy のため安全に JavaScript でカスタマイズができるといった利点があります。 このサブドメインを実現しているのは、従来 Apache で実装されたリバースプロキシでした。しかし、この時の実装はサブドメインごとに異なる VirtualHost を定義する方式で、お客様サブドメインの数に比例して Apache の設定を変更する時間が伸びていくというものでした
バッチを高速にした後はリアルタイムの世界へ！ 現在、さまざまな業種の企業でビッグデータ分析の取り組みが行われている。ビッグデータへの最初の取っ掛かりは、既存のバッチ処理の高速化や、大量の業務データを用いた分析レポートの作成という企業が多いことだろう。そして、バッチ処理の高速化が一段落した次のステップとして、「リアルタイム処理」をテーマに掲げる企業も多いかと思われる。具体的には、 直近10秒間のトラフィックを集計したい。 直近10分間で自社商品がTwitterで話題になった回数を知りたい。 直近10時間での全店舗での来客数を集計したい。 といったリアルタイムなモニタリングを実現したくなるのではないだろうか？こういったモニタリング用の集計は、技術的には「ウインドウ集計（Time-Window Operation）」と呼ばれる。そこで本コラムでは、近頃、「ポストHadoop」として話題のApac
仕事で使っているPHPアプリケーションをPHP7 beta1で動かしてみたらそのままでは動きませんでした。 私が実際にはまった点を紹介します。 なお、PHP7の変更点についてはhnwさんの記事に詳しく網羅されているのでご一読ください。 PHP7で変わること - hnwの日記 Apacheのモジュール名が変わっていた ApacheにPHPを組み込むためのモジュール(俗にいうmod_php)のモジュール名・ファイル名が変更になっていました。 LoadModule php5_module modules/libphp5.so ↓ LoadModule php7_module modules/libphp7.so memcache extensionがインストールできない PHPからMemcachedを使うためのExtensionには２つあります。 memcache memcached memca
Apache Spark を今後活用していくに当たって行ったプレ検証の結果について slideshare にアップロードしました。 もう少し詳細な内部の実装や挙動を見ていかないとと思いつつ、いい加減ワードカウントも飽きてきたのでデータ分析にトライしていきたいと考えております。
※2014-12-18 追記※ はてブとかtwitterがついててちょっとビックリしてます． そしてtwitterで貴重なご意見をいただきました． 1024以下でもう少し増やすとどうなるかなぁ。workerに偏りがあってエラー出てるのかも。例えば8*768とか。 / “nginx の worker_connections は worker 当たりの同時接続数だと思ってたけどど…” http://t.co/5aLNa0VeOy— MATSUMOTO, Ryosuke (@matsumotory) 2014, 12月 16 なるほどー． ということでworker_processes 8, worker_connections 768でざっくりですが早速試してみました． 結果，worker_connections are not enoughエラーは見られなくなったように思います． # というの
共有レンタルサーバのWeb機能提供において、単一のApache httpdでVirtualHost機能により複数のホストを仮想的に処理する場合が多く、その際に重要になってくるのがCGI等の動的コンテンツを適切に権限分離しセキュリティを担保する事です。 静的コンテンツの権限分離の必要性 しかし最近では、動的コンテンツだけでなく静的コンテンツも権限分離をしないと、共有レンサバのように各ホストが自由にファイルを操作できる状況では、セキュリティ上の問題があるという話が出てきました。 具体的には、シンボリックリンクをApacheで無視する設定にしていたとしても、各ホストの管理者（共有レンサバのユーザ）がシンボリックリンクをファイルシステム上に作成できてしまう時点で、悪意のあるユーザがApacheの仕様に伴うシンボリックリンク検査のレースコンディション問題を利用してシンボリックリンクを自由に設置し、他
Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ の続き。 前回は、rpm / deb パッケージを作るために、CentOS、Debianなど各種ディストリビューションを揃える手間をかけずに、Docker コンテナ上でパッケージングして、ついでに Jenkins で CI するみたいなことを書いた。 今回は、作成したパッケージを yum / apt リポジトリに登録して yum / apt コマンドでパッケージインストール/アップデートできるようになるまで継続的インテグレーションするという話。 問題点 yum / apt リポジトリ用の専用ホストを立てて、そこで apache とかで静的ファイルをホストするのはめんどくさい。 特に、mackerel-agent みたいなユーザにインストールしてもらうパッケージの場合、リポジトリを公開し
開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での
サーバを運用していらっしゃる方であれば、サービスの停止は死に値します。 大事な事なのでもう一度言います。 サーバを運用していらっしゃる方であれば、サービスの停止は死に値します。 サーバ管理者は皆、突然の死に備えるべきです。 そんな過酷な場面に立ち向かうサーバ管理者の皆さんの苦労を少しでも軽減する為に、apache モジュールを書きました。 mattn/mod_suddendeath - GitHub 突然の死! https://github.com/mattn/mod_suddendeath まずコンパイルしてインストールします。 apxs -ci mod_suddendeath.c -lhttpd -lapr-1 そして apache を再起動します。 サービスが動作しているディレクトリの .htaccess に以下を書き込みます。 SetHandler suddendeath すると
はい、これは僕がいつも良く見る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
レシピブックはDjangoを使ったレシピサイト向けCMSです。 レシピサイトというのは世界中で人気があります。特に食材、料理の種類が豊富な日本では利用者も多いです。そんなレシピサイトを自分で構築したいと思ったら使ってみたいのがレシピブックです。 メイン画面です。 レシピブックを使ったサイトです。レシピの一覧です。 レシピの詳細です。 材料が細かく載っています。 検索結果です。 検索結果の下にレシピが載った場合の表示です。 レシピブックはDjangoを使っており、データのメンテナンスに際してDjangoの管理画面が使えます。特徴としてコンテストの開催機能、Apache Solrによる全文検索、Apache ActiveMQを使ったタスクキュー、Amazon S3へのファイル保存機能があります。 レシピブックはPython/Django製のオープンソース・ソフトウェア（MIT License）
XAMPPやMAMPを使えばMacでも簡単にLAMP環境を導入することができますが、それらを使わずに構築する方法です。LAMP構築には[Apache] [MySQL] [PHP/Perl/Python] が必要ですが、MacはデフォルトでApacheとPHP／Perlが導入されているので、MySQLとデータベース管理用にphpMyAdminを入れてLAMP環境を構築します。ついでにバーチャルホストの設定をしてサイトごとに専用のドメインを割り当てます。 MySQLをインストール 下記サイトよりMySQLをダウンロードします。 Download MySQL Community Server ※：MacPortsからもMySQLをインストールできますが、時間がかかる上に、後述するシステム環境設定の項目が追加されないので手動でインストールします。 ダウンロードし、展開orマウントして開くとインスト
今日はさくらVPSに載せているWordPressのパフォーマンスをチューニングして高速化に成功したので安心して眠れるという話をします。 2.5ページ/秒だったのが70ページ/秒と30倍高速化。 以前はDaily数千PVで重くなっていたサイトがDaily3.6万PVを余裕で捌けるようになりました。 #ちなみにproxy cacheという手法はwordpressでなくても動的コンテンツ全般に有効です。 ▼サーバ気にしなくて良くなったので今週末新宿御苑に花見に行けました☆。枝ぶりがいいさくらが多くてほんといいところだと思うの。 WordPressチューニング高速化結果http://hara19.jp/のサーバ環境と測定結果は以下のとおり。 WordPress稼働環境さくらVPS 1GB/CentOS5.5/PHP5.3/MySQL5.5/WordPress3.1。 WEBサーバはチューニングにあ
手元の開発用マシンでapacheを再起動する度に次のような警告メッセージが出ていたのがずっと気になっていた。 hiraku@hirakuro:/etc/apache2/sites-enabled$ sudo /etc/init.d/apache2 restart Forcing reload of web server (apache2)...apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName 何度か、調
既存WEBサイトをIPv6対応にするには？を色々と調査してみました。 今年の後半にはIPv4アドレスが枯渇するということで, もっと先のことと思っていたらすぐそこに来てしまいましたね。 基本現行のサイトはIPv4ベースで動いていると思いますが、apache等上で当ブログのようにサーバ運用している場合に影響がないか心配な方も多いのではないだろうか、ということで調べてみました。 IPv6とは？ まず、IPv6ってどういうものか？個人的に知識が曖昧な部分が多かったので改めて調べてみます。 IPv6 - Wikipedia はしょると、42億個が上限のIPv4を拡張して、約340澗(340兆の1兆倍の1兆倍)まで扱えるようにしたとあります。 これだけあれば枯渇とは無縁ですね。 IPv4 では「192.0.2.1」みたいなものだったのが、IPv6になると「2001:0db8:bd05:01d2:28
わたしのいるチームは１１時集合なのですが、集まりがあまりよくありません。 １１時半くらいに、出社していない先輩に「◯◯さん起きていますか？」とメール。 ↓ 返信が来たらIRCに「◯◯さん今起きたそうです！」と書きこむ。 といった業務フローをだいたい毎日行っています。 自動化できないか、という話も出たのですが、決まった時間にメールってそれ目覚ましと一緒だし、習慣づいちゃって起こすのが難しくなりそう？という話になって、現状のままです。温かみのある、人の手によるメールの方がきっと効果が高いという結論に。 でもおもしろいので、メール送るところだけ書いてみました。 サンプルとしてYoshioriさんの名前を出しましたが、Yoshioriさんが遅刻ばっかりしているわけじゃないですよ！ package jp.ne.hatena.syoko_sasaki; import org.apache.common
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
