tl;dr AWS Game Day というイベントに初老、初老界隈のメンバー三人で参加した。 gameday-japan.connpass.com AWS Game Day とは...上記のサイトを抜粋。 AWS GameDayはAWS上に構築されたシステムのトラブルシュートコンテストのようなものです。 主催者より皆さんに、"ある"AWS環境を払い出します。皆さんは払い出された環境を、どんな負荷ににも耐えられる最強の環境にするコンテストです。 参加者の中で最も優れた環境に育て上げたチームがチャンピオンになります！いわば、ドラゴンボールの天下一武道会のようなものです。 詳細な内容は書くことは出来ないけど、イタズラ好きな CTO のもとで働くインフラエンジニアというシチュエーションで、高負荷に耐えうる環境を構築するミッションをそれぞれのチームで競うというもの。参加者には ISUCON 入賞者

追記 直近の Docker 界隈について Linux コンテナ 参考 Linux コンテナとは Linux コンテナを構成する主な機能 OS リソース毎の Namespace cgroup サブシステム こんなにざっくりでは、Linux コンテナは語れないと思うけど haconiwa haconiwa とは haconiwa で何が出来ると？ haconiwa 導入 はじめての haconiwa (1) はじめての haconiwa (2) 〜 コンテナ作成 〜 はじめての haconiwa (3) 〜 コンテナ起動 〜 haconiwa で学ぶ Linux コンテナ .haco ファイル再掲 namespace を弄る前に namespace uts namespace pid 俺は Linux コンテナについてなんにも解っていなかった(まとめ) haconiwa は Linux コンテ

エブリデイ試した系ですいません。かっぱです。 tl;dr inokara.hateblo.jp の続き。 AWS CLI で ALB を作成して ECS の Service を作成して ALB と組み合わせてみる。尚、ALB を操作するには elbv2 というサブコマンドを利用する。 メモ ちょっとウンチク ここまで試してきて Amazon ECS と AWS Application Load Balancer は以下のような構成になっていると理解。 Listner で ALB がインターネットからの接続を何番ポートで Listen するか定義する Path Pattern 毎に Target Group を定義する Target Group には EC2 インスタンスやコンテナをぶら下げることが出来る（バックエンドへのルーティングやヘルスチェックについて定義する） ALB の詳細について

ども、ECS は最近全然触れていないかっぱです。 追記 AWS CLI のでも操作してみた。 inokara.hateblo.jp tl;dr 先日、AWS Application Load Balancer がリリースされて、Amazon ECS の Dynamic Port Mapping にも対応されたとのことで、ECS と Application Load Balancer の組み合わせを試行錯誤している。内容な認識等に誤りがあるかもしれないのでご容赦下さい。 https://aws.amazon.com/jp/blogs/aws/powerful-aws-platform-features-now-for-containers/ https://aws.amazon.com/jp/blogs/aws/new-aws-application-load-balancer/ 試した環境

はじめに 先日、DevOps 向け Fluentd 勉強会 at IPROS で聞いた話の中で Ouptput プラグインのバッファの関して下記の点について気になったので調べたくてウズウズ。 Output プラグインのメモリバッファとファイルバッファの性能はほとんど差異は無い デフォルトはメモリバッファだがファイルバッファがオススメ また、fluent-logger を使ってサーバーの負荷が激しく上がってしまった件について質問させて頂いたがよくよく考えるとこのバッファについて全く考慮しないままの利用だったので、この件でも解決への糸口になるのではということでメモリバッファとファイルバッファで何が違うのかを調べてみた。 構成 検証環境 以下のような検証環境を用意した。 役割 バッファタイプ / Output / アプリケーション OS td-agent バージョン スペック 備考 Forwar

モチベーション RDS の勉強をしたい→スロークエリの設定を見てみよう RDS のスロークエリをお手軽に可視化出来ないものか Elasticsearch + Fluentd + Kibana(EFK スタック) を改めて勉強したい 実サービスへの影響を極力抑えたい 可視化する手間は極力省く ということで、Elasticsearch + fluentd + Kibana + docker-compose を利用することで、ほぼコマンド一発で可視化する環境は起動する環境を作ってみた。 github.com 参考 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html https://github.com/kenjiskywalker/fluent-plugin

はじめに elasticsearch 1.0.0 が正式にリリースされたので改めて Snapshot と Restore 機能を試してみる スナップショットの仕組みについて少しだけ深堀りしてみる 操作 EC2 インスタンス上に構築した elasticsearch 1.0.0 リリース版を利用して操作する。また、データ自体はライブドアが提供しているこちらのレストランデータを利用する。 上図の restaurant インデックスを題材に Snapshot と Restore 機能を試してみる。ちなみにリクエスト内の ?pretty はお好みで。 リポジトリの一覧 curl -XGET "localhost:9200/_snapshot/?pretty" 以下のように表示される。 { "my_s3_repository" : { "type" : "s3", "settings" : { "re

tl;dr 手作業で構築した AWS リソースの管理には以前から気になっていた awspec が良いと思ったのでメモ。 二台、三台のインスタンスなら...とうっかりと手作業で構築したインスタンスや、どんな設定で作ったか判らないけど、なんとなく利用されている S3 Bucket の管理をどうしようかなと思っていたら awspec の generate コマンドがリソース情報を生成してくれるので試してみた。 参考 github.com qiita.com memo インストール $ cat Gemfile source "https://rubygems.org" gem 'awspec' gem 'rake' $ bundle 初期化 $ bundle exec awspec init + spec/ + spec/spec_helper.rb + Rakefile + spec/.giti

ども、初老丸です。 tl;dr Linux において tc コマンド（Traffic Control）使ってネットワーク遅延やパケットロスを疑似的に発生させることが出来るとのこと。今まで tc コマンドの存在すら知らなかったペーペーで恐縮だが、参考サイトをまねて遅延やパケットロスを発生させてみたい。 メモ 参考 http://linux-biyori.sakura.ne.jp/setting/st_netem.php http://labs.gree.jp/blog/2014/10/11266/ man tc 以下の環境で試す。 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" ひとまず

はじめに 今さらジローではあるが、自分の中で Docker を絡めたクラスタ構成について気になっているので CoreOS やその関連技術を改めて勉強してみたいと思う。CoreOS 等の各種情報については参考にさせて頂いた記事がとても詳しく参考になるので、そちらを都度確認しつつ理解を深めていきたい。 今回は以下を学びたい。 Vagrant で CoreOS ノードを複数起動する etcd と fleet をザクっと触る fleet で Docker コンテナクラスタを管理する 起動したコンテナのサービスを registrator で etcd に登録する etcd に登録したサービスの情報を利用して HAProxy の設定に反映させる 構成 今回、教材として利用する構成は以下の通り。 参考 http://deeeet.com/writing/2014/11/20/fleet/ http://

追記（2015/08/14） Docker 1.8 のリリースに含まれていた追加仕様 により dd-agent からホスト側 cgroup のマウントポイントが見えない状態が発生していたようだ。 github.com 既に上記にて対応済みとなっているが、まだ dd-agent の最新版には反映されていないので注意が必要。すぐに対応が必要な場合には以下のように最新の docker.py を取得して独自にコンテナをビルドする必要があると思われる。 $ git diff Dockerfile diff --git a/Dockerfile b/Dockerfile index 17f11f5..d4a1343 100644 --- a/Dockerfile +++ b/Dockerfile @@ -26,7 +26,12 @@ RUN mv /etc/dd-agent/datadog.conf.

ども、かっぱです。 はじめに Java アプリケーションを運用する上では避けて通れないであろうヒープ領域の監視についてフワッと考えてみた JVM には幾つか領域があるがヒープ領域に焦点を当てる 参考 http://www.whitemark.co.jp/tec/java/javaHeap.html http://www.whitemark.co.jp/tec/java/javagc.html http://d.hatena.ne.jp/ogin_s57/20120623/1340463194 http://d.hatena.ne.jp/ogin_s57/20120709/1341836704 https://docs.oracle.com/javase/jp/1.5.0/guide/management/agent.html http://chonaso.hatenablog.com/en

はじめに とりあえず sensu で監視環境を作りたい Sensu についてはこちらやこちら、こちら等で詳しく纏めて頂いていて参考になる chef とか puppet での構築が推奨されているが、今回はこちらを見ながら sensu-server の構築をやってみる EC2 上の Amazon Linux 上に構築する 参考 Sensu Documentation 最低限必要なツールをインストール rabbitmq sudo yum --enablerepo=epel install rabbitmq-server sudo chkconfig rabbitmq-server on sudo /etc/init.d/rabbitmq-server start redis sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-r

どうも。最近ネタ切れ感が拭いきれない docker 初心者を抜け出せないかわはらです。 はじめに docker でコンテナ内であれこれしたデータの永続化したいな案件が発生したので調べて試した ついでに Amazon Linux で docker が使えるようなのでそっちで試した 参考 Share Directories via Volumes DockerのVOLUMEを調べてみた。 コンテナ型仮想環境におけるデータの永続化の必要性 小難しいタイトル↑だが自分は以下のように考えている。 データの永続化は出来たら嬉しい でも、そもそも破棄が前提の環境においてデータの保存は検討しない（保存しない） ログの類はコンテナをホストしている環境等（コンテナ以外の環境）に fluentd 等を使って流してそちらで保存する ということで、永続化に関してはコンテナ自身でどうこうではなく外部に保存というのがイ

はじめに docker の UI ツールがあったのを思い出したので使ってみる いくつか種類があるが今回は dockerui を試す docker のコンテナとして配布されているもので試してみる 参考 crosbymichael / dockerui Docker上でDockerUIを試してみる Docker Remote API dockerui とは リポジトリはこちら dotcloud の Michael Crosby さんが作られている go をはじめ Angular.js や Flatstrap 等で実装されている docker remote API 利用する 詳細は README を確認すること セットアップ README に詳しく書かれているのでそちらを参照するのが良い。 試した環境 ホストは Ubuntu 13.04 docker のバージョンは 0.6.2（すでに 0.6.

概要 CoreOS を Vagrant で利用した CoreOS 内で docker を使って Ubuntu のイメージを作成した Ubuntu のイメージ内に Ruby 2.1-preview1 と fluentd をインストールしたイメージを作成した 作成したイメージを index.docker.io にコミットする（ところまで出来れば嬉しい） 参考 Running CoreOS on Vagrant CoreOSでDocker入門 仮想環境構築に docker を使う Docker を読む Docker = LXC + aufs + GitHub Culture ウンチク CoreOS とは Linux Kernel と systemd だけで実装されたシンプルな OS Chrome OS がベースとなっている Docker と組み合わせて OS のアップデートを行う CoreOS

きっかけ せっかくなので Elasticsearch を深堀してみた Elasticsearch とは Elasticsearch とは... Apache Lucene をベースに作られた RESTful な検索エンジン JSON で設定や検索が可能 スキーマレスなのでデータをジャンジャン放り込める（？） 使ってみる こちらのスライドを参考にして色々と触ってみた。 とりあえず Elasticsearch はこちらで既にインストール済み 起動するとサーバーの 9200 ポートで Listen する インデックス（データ登録） 以下のようにデータ登録が行われる。 データの取得 以下のようにデータ取得が行われる。 データの検索 user が kappa で登録されているレコードを検索すると以下のように 2 レコード登録されているのがわかる。 ということで kibana との連携については ki

はじめに Fluentd Casual Talks #3 で norikra の作者である @tagomoris さんのお話を伺ってからずっと試したいと思っていてやっと試せたのでアウトプット。 参考 Norikra 0.1を使ってみた Norikraで遊んでみた fluent-plugin-norikra #fluentdcasual Norikra in action http://esper.codehaus.org/ 5.1. EPL Introduction 5.2. EPL Syntax norikra とは 自分の認識、でも百聞は一見に如かず ちゃんと理解出来ていないけど...以下のような認識でいる。 ログ等のストリームデータを SQL ライクなツールを使って検索出来るツール 例えば、fluentd で処理しているログに対して SQL に似た感じの検索クエリを投げて結果を処理出