This domain may be for sale!
![crocos.jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/eea24f393102de00b8bbdd0cb93cd6a5a16bf83f/height=288;version=1;width=512/http%3A%2F%2Fres.cloudinary.com%2Friaf%2Fimage%2Fupload%2Fv1378448851%2Fengblg_logo_jze44s.png)
このウェブサイトは販売用です! dream-web.info は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、dream-web.infoが全てとなります。あなたがお探しの内容が見つかることを願っています!
#alias docker='sudo docker' # pecoで選択したコンテナに対して操作を行う docker_peco_containers() { if [ $# -lt 1 ]; then echo "Usage: dpc [OPTIONS] COMMAND [args]" >&2 return 1 fi docker ps -a | peco | while read CONTAINER do docker $@ `echo $CONTAINER | awk '{print $1}'` done } # pecoで選択したイメージに対して操作を行う docker_peco_images() { if [ $# -lt 1 ]; then echo "Usage: dpi [OPTIONS] COMMAND [args]" >&2 return 1 fi unset DOCK
追記(2014/07/25) KairosDBに関して、HBaseは現在サポートしていないことが判明したので一部修正し、リンク先も現状のアドレスに変更しました。nobusueさん、情報ありがとうございます! わりと最近時系列データベースという単語を聞くようになったが、告白すると寝耳に水状態でちょっとあせったので軽く調べてみた(きっかけはこの過去記事)。 時系列データベースとやらは国内だとサーバー監視・モニタリングの分野から広まり始めてる印象だが、元々はセンサーデータ、M2M、IoTといったキーワードと相性がいいものらしい。 (ところで IoT: Internet of Things って日本では直訳調で「モノのインターネット」と言われるが、これだと何のことだかわからん。この言い方じゃ普及しないと思うぞ…) 「時系列データベース」と書いたが、プロダクトによってはデータベースという定義ではなく
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
ども、大瀧です。 本日、AWSで使用できるロードバランササービス、ELBでタイムアウト値変更のオプションが追加されました。これまでは、AWSサポートに個別に連絡しAWS側で変更するという手続きでしたが、ユーザー側で自由に設定できるようになりました!!また、上限も以前は17分でしたが、今回のアップデートでなんと最大60分まで設定できます。 ELBのタイムアウト値とは ELBは、ロードバランサのサービスとして一般に言うリバースプロキシの機能を持ちます。処理の流れを以下に示します。 ELBはクライアントからのリクエストを受信し、EC2インスタンスに転送する EC2インスタンスはELBが転送したリクエストに対応する処理を実行する EC2インスタンスはレスポンスとしてELBに処理の結果を返送する ELBはEC2インスタンスのレスポンスをクライアントに転送する 今回のタイムアウト値は、上記手順の2と3
ログをfluentdからelasticsearchに流し込みKibanaを使って表示させるため、elasticsearchとKibanaをセットアップした時の備忘録。 セットアップするサーバ EC2 (Amazon Linux) elasticsearchのインストール $ wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.1.noarch.rpm $ sudo rpm -ivh elasticsearch-1.0.1.noarch.rpm $ rm elasticsearch-1.0.1.noarch.rpm /usr/share/elasticsearch以下に本体がインストールされた?? /etc/elasticsearch/elasticsearch.ymlが設
AWS EC2上にfluentd + fluent-plugin-twitter + elasticsearch + kibana インストールするメモAWSFluentdElasticsearchKibana AWS EC2上にfluentd + fluent-plugin-twitter + elasticsearch + kibana インストールするメモ。 0. instance立ち上げ EC2上にinstanceを立ち上げる。 とりあえず、お試しならt2.microでも良いかも。 AWS t2.micro OS: Amazon Linux AMI (HVM) ツール、データはS3上に上げておくと、外部からダウンロードするより少し早いし、お財布にも少し優しい。 1. yum update
最近話題のDockerやGoogle Cloud Platformを用いて大規模データのための解析基盤を作ります。今回はデータソースとしてTwitter Streaming APIを利用しますが、アクセスログなどに応用することももちろん可能です。コードは一行も書きません。解析基盤をつくためにマシンを用意する必要はもちろんありません。 BigQueryについては、 Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja が参考になります。 利用するプロダクト/サービス Google Cloud Platform Google Compute Engine BigQuery Docker fluentd fluent-plugin-twitter fluent-plugin-bigquery Twitter Streamping API 想
スケールアウトしたサーバは、負荷がなくってきたら基本的にTerminateします。 Terminateする前にapacheのアクセスログは退避したいものです。 かと言って、各サーバからアクセスログをダウンロードするのは、少し面倒になります。 そんな時は、Terminate前にs3にコピーをすると便利です。 例えば21:00にTerminateすることが決まっているとします。 そんな場合は、下記のようなスクリプトを20:55などに設定しときます。 (前提条件としてs3cmdコマンドがインストールされているとします。) #!/bin/sh FILE=/var/log/httpd/access_log DATE=`date +%Y%m%d` HOST_NAME=`hostname` cd /var/log/httpd/ cp -pr access_log ${HOST_NAME}_access_
今回、AWSのAmazon Kinesisを触る機会があり、AWS SDK for Androidを使用して接続してみたので、その際の手順をまとめてみました。 事前準備 Kinesisの起動 まずは、Kinesisでストリームを作成します。 ストリームの作成方法はこちらが参考になります。 【AWS】Kinesis 東京リージョン始まりました。 今回は、Stream Name : exampleKinesis , Number of Shards : 2 で作成してみました。 Access Key, SecretKeyの取得 Android SDKでAWSにアクセスするには、AWSのAccess Key, Secret Keyが必要になるので、取得しておきます。 取得方法はこちらを参照してください。 AWS SDK for Androidの取得 SDKをダウンロードしておきます。 AWS S
AWS Summit Tokyo 2014 TC-09 で発表した資料になります。 タイトル:TC-09「AutoScale×ゲーム ~運用効率化への取り組み~」について === イベント概要 === AWS Summit Tokyo 2014について 開催日:2014年7月17日(木)~18日(金) 9:15 ~ 19:00 会場:グランドプリンスホテル新高輪 (国際館パミール) 主催:アマゾン データ サービス ジャパン株式会社 サイトURL:http://www.awssummittokyo.com/ スケジュール:http://www.awssummittokyo.com/schedule.html セッション紹介:http://www.awssummittokyo.com/session.html#tc9 後半 => http://www.slideshare.net/Takas
今月から社内勉強会は、社員が持ち回りで講師を担当することになりました。 初回のテーマは「MySQLのトランザクション」です。 MySQLにほぼ限定した形でトランザクションについて発表をしました。 資料は以下の5章立てになっています。 1.トランザクションとは 2.ストレージエンジン 3.トランザクションの開始と終了 4.ACID特性 5.オートコミット 日頃の業務では、実行したSQLの動作確認をした際に、意図した結果が得られない場合に処理を戻せるように、「begin」で書き始めてトランザクションを開始するようにしています。 しかし、そもそもトランザクションは「失敗した時に戻すための機能」ではありません。 普段から使ってはいるけれど深くは知らなかったトランザクションについてちょっとだけ知識を深めるよい機会になったと思います。 なお、「2.ストレージエンジン」の中で、MySQLで利用できるスト
コンテナのリンク(連結)と操作 Linking containers together - Docker Documentation http://docs.docker.com/userguide/dockerlinks/ Using Docker section において、私たちはネットワークを通して Docker コンテナの中で実行されているサービスにつながる事に触れてきました。これは、Docker コンテナの中で、サービスと動作中のアプリケーションを相互に作用することが出来る方法の1つです。このセクションでは、リンクしている(連結している)コンテナに概念を導入するだけでなく、ネットワーク・ポートを通して、Docker コンテナへの接続をリフレッシュさせる方法を扱います。 ネットワークポート割り当てのリフレッシャー Using Docker section において、私たちは Pyt
mysqldの --general-log-file オプションを /dev/stdout に設定してコンテナを起動しておく。 $ sudo docker run -p 3306:3306 -d --name mysql -e MYSQL_ROOT_PASSWORD="mypass" mysql /entrypoint.sh mysqld --datadir=/var/lib/mysql --user=root --general-log=true --general-log-file=/dev/stdout こうすることで、docker logs -f mysql で標準出力にてクエリーログを確認できるようになる。 ホストとコンテナでログファイルをVOLUMEで共有しなくていいのがこの方法のいいところ。また、ログファイルを確認するためにコンテナに入る必要もない。Dockerfileやmy
MySQLの更新系処理のパフォーマンスを、innodb_flush_log_at_trx_commitのチューニングで上げる 経緯 Master(更新系のMySQL Database)が非常に高負荷となっている。 slowquerylogsに、下記のような「commitがボトルネックになっている」旨の出力が大量にでる # User@Host: apps[apps] @ ip-10-163-30-24.ap-northeast-1.compute.internal [10.163.30.24] # Query_time: 9.523171 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 SET timestamp=1349786490; COMMIT; # User@Host: apps[apps] @ ip-10-132-8-20.ap-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く