elasticsearch, kibana環境をDockerでさくっと準備する
環境情報
- Docker for Mac Version1.12.0-beta21
Docker Image取得
公式のイメージが提供されているので、それを使う。
docker pull elasticsearch
docker pull kibana
コンテナ起動
いくつかブログ見た感じ、これでいいらしい。
docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 elasticsearch
docker run -d --name kibana --link elasticsearch:es -e ELASTICSEARCH_URL=http://es:9200 -p 5601:5601 kibana
確認
下記ページにアクセスして、「Status: Green」になっていればよい。
http://localhost:5601/status
プロジェクトが縦割りか見分ける方法
自分なりに納得感のある「プロジェクトが縦割りか見分ける方法」を思いついたので、日記に残しておきます。
まず本文を読むにあたっての前提を記載します。
- 本文章では「縦割りなプロジェクト」の対義語を「一体感のあるプロジェクト」としています。
- 本文章ではある１つのシステムやサービスを開発する集団のことを「プロジェクト」、プロジェクト内で役割によって分かれた集団のことを「チーム」と記載します。
イメージとしては、プロジェクトは○○更改プロジェクト、チームはＡ業務チーム、B業務チーム、基盤チームといった感じです。
この前提で「プロジェクトが縦割りか見分ける方法」を述べると、「プロジェクトが縦割りか見分ける方法」それは「チームをまたがる技術的な課題の解決策をわくわく感を持って議論できるかどうか」です。
一体感のあるプロジェクトは、チームをまたがる技術的な課題の解決策をわくわく感を持って議論できますが、
縦割りなプロジェクトは、チームをまたがる技術的な課題の解決策をわくわく感を持って議論することはできないと考えます。
何故こう考えたかということ、チームをまたがる技術的な課題の解決策を議論するというのは、本来的にはエンジニアにとってわくわくする楽しいことだと思うからです。
エンジニアの方であれば、ある技術的な課題を「こういう技術があれば課題は解決するのに」「その技術ってこうやったら実装できるんじゃない？」「あ、それならできそう、チャチャッとやってみるか」といった感じで、楽しく議論したことがあると思います。
一体感のあるプロジェクトであれば、議論した内容がプロジェクトに本当に必要ということになれば、チーム間で作業の優先度勘案した上で、プロジェクトとして課題を解決するためのアクションを取れると思うんですよ。
縦割りなプロジェクトというのは、このチーム間の調整ができないのだと思います。
だから、本来的には楽しい技術的な課題のディスカッションの場が、作業の押し付け合いのような様相を呈してしまうのだと思います。
明らかにまとまってないんですが、今思っていることの骨子は書けたので、とりあえず文章を公開しようと思います。
また何か考えたら書きます。
このページはtoggleボタンのサンプルページです
要素の表示・非表示を切り換える、それがtoggleボタンです。
この機能を使って、画像の切替も実現可能です。
なお、説明と画像は一切関係がありません。
この機能を使って、画像の切替も実現可能です。
なお、説明と画像は一切関係がありません。
yaml.erbをyamlに変換するスクリプト
yaml内で変数を使いたかったので、erbと組み合わせて実現した。
個人的な備忘録として書き残しておく。
早速だがyaml.erbをyamlに変換するスクリプトは以下の通り。ファイル名はymlerb2yml.rbとする。
require 'erb' require 'yaml' # VARIABLE DEFINITION var1 = 'bbb' var2 = 'ddd' # FORMAT TRANSLATION yml_erb = ARGF.read() ruby_data_type = ERB.new(yml_erb).result(binding) yml = YAML.load(ruby_data_type) puts yml.to_yaml()
動作確認には以下のyaml.erbを用いる。ファイル名はtest.yml.erbとする。
- aaa - <%= var1 %> - ccc_<%= var2 %>: eee
実行結果は以下の通り。
# ruby ymlerb2yml.rb test.yml.erb --- - aaa - bbb - ccc_ddd: eee
ワンライナーでやると以下の通り。
# ruby -r erb -r yaml -e "var1 = 'bbb'; var2 = 'ddd'; puts YAML.load(ERB.new(File.open('test.yml.erb').read).result(binding)).to_yaml()"
---
- aaa
- bbb
- ccc_ddd: eee
こんな感じでやりたかったことやれたっぽい。
Ruby / Rails ビギナーズ勉強会（第11回）登壇レポート
- [3/16追記] 発表動画をYouTubeに挙げていただいたので、リンクを貼りました。
2月27日(土)にRuby / Rails ビギナーズ勉強会で発表してきた。
タイトルは「Railsチュートリアル完走後の次の一歩」。
発表資料はこちら。
準備や発表を通じて感じたことを簡単にまとめる。
スライド作成
- スライドのデザインを考えるときはまずノンデザイナーズ・デザインブックを参照した。特に配色の考え方が参考になった。
- 文字色のベースを黒じゃなくて灰色すると綺麗というツイートを見て、そのようにした。
- フォントは「Noto Sans」が綺麗と聞いて試してみたが、「Meiryo UI」のほうが好きだったので、そちらを使った。
- 今回の発表資料はそれなりに時間をかけてこだわれたので、今後また発表資料作るときはこれを参考にしようと思う。
- クリップアートや画像を探すのにやたら時間がかかってしまった。会社だと会社でクリップアートを用意してくれていて、それを使えばいいのだけど。
発表
- 練習のとき12分くらいかかっていたので、ちょっと急ぎ目でやったら8分かからず終わってしまった。かなり早口になってしまっていたと思う。反省。
- 発表練習しまくって、できれば資料の内容は暗記しておきたいと思った。スクリーン見るために後ろ向いたり、手元のノートPC見るために顔を落とすのは見栄えが良くないので。
発表内容
- 資料を作る前は、内容簡単すぎて発表する意味ないかと思ったけど、資料を作っていたら、それなりに意味のある資料を作れている気がしてきた。
今作っているアプリをとりあえず作りきって、今年中にもう一回発表したいと思う。
発表動画
Amazon Aurora東京ローンチ記念セミナー参加レポート
11/10(火)、目黒で開催されたAmazon Aurora東京ローンチ記念セミナーに参加してきたので、レポートをまとめておく。なお、数値などは聞き間違いがあるかもしれないので、詳しくは発表者の資料や公式のドキュメントを参照してほしい。
セミナーの感想
セミナーを通してAmazon Auroraはエンタープライズレベルの要件に耐えうるスケーラブルなRDBMSであると、自分なりに咀嚼して理解できたのがよかった。
Auroraの特徴のうち、特に衝撃だったのは次の3点だった。
- MySQLの5倍の性能
- 秒オーダでのフェイルオーバ
- Auroraはマスタは1つなので、マスタ障害時にはフェイルオーバが発生する。リードレプリカがある場合、フェイルオーバ時間は30秒ほど。MariaDB Connectorと組み合わせたら1～2秒になったという事例がある。
- お手軽マイグレーション
セミナー後調べたこととか考えたこと
- Auroraの資料見たところ、なんとAuroraはPostgreSQLと同じ追記型らしい。
これによりバックアップなどの運用性向上、書込性能の向上が実現されているとのこと。 - Auroraは可用性99.99％で設計されていて、SLAは99.95％とのこと。この数字が今後向上したら世の中のシステムはどうなるんだろう。
- NoSQLが出てきたとき、「NoSQLがRDBMSに取って代わることはなくて、適材適所で使われるようになる」という話があったと思う。
これに対してAuroraは、「Oracle, SQL Server並みの性能を、MySQL, PostgreSQL並みのコスト、運用性で」というセミナーでの発言が示すとおり、これから全てのRDBMSの領域を置き換えていく可能性のあるサービスだと思った。 - これからもたくさん事例が出てくると思うので、そのあたりウォッチしていこうと思う。
以降はセミナー中に取った聴講メモなど。
はじめのあいさつ
最初はAWSJ安田さんの挨拶。
Talend、DataSpiderといったデータ連携のツールが既にAuroraに対応。
ウイングアーク1st株式会社は自社製品の中でAuroraを使っているとのこと。
Using Amazon Aurora for Enterprise Workloads
AuroraのGMのDebanjan Sahaさんのお話。
聴講メモ
- Auroraはエンタープライズ利用を想定して設計してある。
- MySQLに完全互換。MySQL向けアプリはそのままAuroraで使える。
- 性能はOracle, SQL Server並、運用のしやすさ、コスト効果はMySQL, PostgreSQLというところを狙っている。
- Master障害時のフェイルオーバ時間は30秒以内。
- MySQLでは数分かかるようなクラッシュリカバリがほぼ即時に実行される。
- 最大50万回/秒の読込、10万回/秒の書込性能。これはMySQLの5倍。
- ストレージ自体がDB用に設計されている。
- これらがフルマネージドサービスになっている。すぐ使えるし、パッチも自動で当たる。
- AWS史上最速で成長しているサービス。
- 国連でも使っている。公開事例になっていなくても、多くの会社がAuroraを使っている。
- 事例1: Expedia
- リアルタイムでのBIと分析が要件。現行はSQL Serverベースのアーキテクチャだったが、高価だった。またスケールしなかった。 そこでCassandraとSolrを組み合わせてインデックスを作成したが、これは大きなメモリー空間が必要で、結局コストが高くなってしまった。
- 事例2: Pacific Gas and Electric Company
- この顧客特有の事情として、停電時にバーストトラフィックが来るので、これを捌かなければならないという事情があった。
- 事例3: ISCS
- 現行ではOracleとSQL Serverを通常業務とDWH用途で使用。これらのコストがIT費用の中で最も大きな支出になっていた。
- Auroraの利用により、70％安価なシステムを実現。
- 事例4: Alfresco
- 事例5: Earth Networks
- 25TB/日で増えるデータの処理をする必要があった。(IoT関連の事業をやっている会社なのかな？)
- 事例6: threat stack
- これもCassandraからの移行事例。
- 高可用性を支える技術
- 3つのAZにまたがり6つの複製を保持。
- Peer-to-pper gossipレプリケーション
- 6つのうち2つを失っても性能は落ちない。6つのうち3つを失っても読み込みは可能。
- 高速なクラッシュリカバリ
- 普通はチェックポイントが5分間隔とかで、ログをシーケンシャルに適用する。時間がかかる。
- Auroraは、Disk readの一環として、オンデマンドでredo logの適用を行う。そのため、リカバリ時にredo logを当てる必要がなく、1秒以内でのリカバリが実現できる。
- AuroraとMariaDB Connectorにより、さらに短時間でのフェイルオーバが可能。
- バックアップについて
- 各DBのスナップショットを定期的かつ並列で取得し、REDOログをAmazon $3へ転送する。
- 適用型スレッドプール
- この辺りはMySQLの実装とかなり違う。(詳細聞き逃した。)
- 非同期グループコミット
- 6つのうち4つのDBでコミットがされた時点で、データの書込みが成功する。
- Advanced monitoring(開発中)
- 顧客からの要望のあった、OS関連メトリクスを取得できるようになる。
- Cloud watchは1分間隔だが、Advanced monitoringは1秒間隔でメトリクスの取得ができる。
- AuroraはMySQLと比べてもコスト効果があることがある。
Q&A
- Q MySQLの場合、データサイズが大きくなるとDDL変更が時間がかかるが、Auroraはそのあたり改善しているのか？
- A いくつかは改善しているが、全てではない。オンラインでのDDL変更については、現在開発中。
- Q モバイルSDKから直接使えるか？
- A 使える。
- Q インスタンスタイプR3しかないが、今後の展開は？
- A 現時点では、T2タイプを今後サポートしたいと考えている。M, CあたりはAuroraのアーキテクチャを活かせないので、考えていない。
- Q メモリに載らない大きなテーブルのalter tableしないほうがいいという話があるが、現在は？
- A おおよそ修正済み。ただ超巨大なテーブルをalter tableするのであれば、大きなインスタンスタイプを利用することをオススメする。
- Q MySQLのMHA(数秒でのインスタンスタイプ変更)のような機能は提供されているか？
- A MHAはサポートしていない。そのような場合の対応方法としては、大きなインスタンスにリードレプリカを作っておいて、そこにフェイルオーバするのを推奨している。
Nice to meet you, Aurora! ～RDS for MySQLからAuroraへの移行～
株式会社Grani @guitarrapc_techさんの発表。発表前に資料公開されていて、ありがたかった。
資料
聴講メモ
- 性能改善について
- NewRelicでざっくり見る。個々のクエリはBigQueryで見る。
- 参照は変わらなかった。
- 更新が5倍速くなった。5倍というアナウンスどおりの結果が出た。
- インサートも速くなった。
- 削除は若干遅くなった。
- 移行について
- MySQLだと高負荷時にダウンしてしまうことがあった。Auroraはスローダウンすることはあっても、動き続ける。
- 年間2200万円のコスト削減効果。
ドワンゴがAurora使ってみた(仮)
株式会社ドワンゴ 細川さんの発表。
聴講メモ
- これまでのはなし
- Aurora適用プロジェクト
- 検証結果・パフォーマンスなど
Amazon Aurora 評価・検証結果発表
アイレット株式会社 cloudpack 新谷さんの発表。
実データを用いたAurora検証結果の報告。
Amazon Auroraはこう使おう！
～基幹業務をフルクラウド化するポイント～
ウルシステムズ株式会社 漆原さんのお話。
聴講メモ
- これまでRDBMSとNoSQLという極端な2択しかなかった。基幹業務系やっていて、ずっとクラウド型のRDBMSが欲しいと思っていた。
- オンプレをそのままクラウドに持っていくと、インフラコストの削減にはなるけど、それしかない。その先へ。
- モノリシックな業務APが、今、すべてを邪魔している。このままAuroraにいっても、それからどうしようもなくなる。
モノリシックなものをマイクロサービスへ。APIで綺麗に切りなおして、そこからしかアクセスさせないようにする。
オーバヘッドはあるが、その代わりスケーラビリティが得られる。こうすることで、Auroraの特性をフル活用できる。
New Cloud Design Pattern using Amazon Aurora
クラスメソッド株式会社 大栗さんのお話。
聴講メモ
- Develpers.IO移行事例
- Developers.IOをAuroraに移行した。性能向上した。
- もともとdb.m3.mediumだったので、db.r3.largeになって、コストは1.5倍になった。
- 某SNS移行事例
- これ以上DBのスレーブ増やせない状態。移行検討中。
- 高速なフェイルオーバ
- OSS DBと比較して低価格の場合もある。インスタンス台数が削減できる場合があるので。
Amazon Aurora＋ScaleArcによる Amazon Aurora のデータベース分散処理技術の最大活用
株式会社システムサポート 山口さんのお話。タイトル違うかも。
ScaleArcという製品の紹介。
エンタープライズシステムにおける Amazon RDS for Aurora 活用ノウハウ
株式会社野村総合研究所 西岡さんのお話。
聴講メモ
- Auroraは可用性99.99％で設計されていて、SLAは99.95％。
- Auroraは現状参照しかスケールしない。
その他
- Amazon Aurora TシャツとAurora利用クーポンの抽選があったけど、外れた。Tシャツ欲しかったな。残念。
- アマゾンのセミナールーム、発表者の立つところに神棚があって、意外と日本ぽいんだなーと思った。
けどよく見たらドアだった。しかもセミナールーム中にいっぱいあった。どういうことなの。
YAPC::Asia2015参加レポート（Day2）
8月21日(金), 22日(土)に、YAPC::Asiaに参加してきた。
YAPC::Asiaは今年で最後ということで、会場はなんと東京ビッグサイトだった。
参加セッション一覧
私が参加した8/22のセッションは次の通り。
- 8/22
- ISUCONの勝ち方 by Masahiro Nagano
- NASA主催の世界最大級ハッカソンSpaceAppsを運営した話 by Tsubasa YUMURA
- Docker３兄弟について by アルパカ大明神
- Adventures in Refactoring by Ben Lavender
- Posture for Engineers by Marylou Lenhart
- Run containerized workloads with Lattice by Etourneau Gwenn
- Profiling & Optimizing in Go by Brad Fitzpatrick
セッションの感想＆内容
参加したセッションの感想や内容を書く。
なお「内容」は、理解し切れていない部分や誤解もあるはずなので、参考程度に見て欲しい。また誤りを指摘できる人は指摘して欲しい。
ISUCONの勝ち方 by Masahiro Nagano
感想
- ISUCONに参加したことはなく、過去問なども見たことはなかったが、毎年Twitterで盛り上がりが伝わってくるISUCONというものがどんなものか知りたくてこのセッションを聞いた。
- プロファイリングツールについての話が興味深かった。言語別のプロファイリングツールもあるが、それよりもstrace, tcpdump, lsof, dstatなどのコマンドのほうが役立つということだった。このあたりのコマンドは使ったことはあるが、使いこなせているかというとそうでもないので、しっかり勉強しておこうと思った。
- コンテキストスイッチの説明、Apacheとnginxのプロセスモデルの違いの説明がわかりやすかった。
- ISUCONの対策資料は結構ネット上にあるようなので、目を通しておこうと思った。
NASA主催の世界最大級ハッカソンSpaceAppsを運営した話
資料
感想
- この発表を聞くまでSpaceAppsを知らなかったが、すごく楽しそうなハッカソンだと思った。こういうハッカソンに参加できるくらいの技術力を身に付けたいと思った。
Docker３兄弟について by アルパカ大明神
資料
感想
- Docker Machineは発表された当初に触ったことがあったが、Compose, Swarmは触ったことがなかったので、使用感知りたくて参加した。
- スピーカーの方は触っただけではなく、開発環境で実際に使っていて、特に問題なく使えているということで、それだけでも貴重な情報を聞けたと思った。
- 副題に～そして4兄弟へ～とあり、Docker4兄弟というのはDocker Networkのことかと思ったけど、Docker Toolkitのことだった。
Adventures in Refactoring
感想
- 業務でリファクタリングをしたことはなくて、ちょっと前までリファクタリングなんて全然興味なかったけど、Rebuildでリファクタリングの話を聞いてから、リファクタリングにはリファクタリングの美学があるんだと知り、そのあたりの話が聞きたくて参加した。発表内容は期待通りリファクタリングの美学についての話だった。
内容
- シングルクウォーテーションとダブルクウォーテーションの両方が使われている箇所をどちらかに揃えて一貫性をとるようなリファクタリングは、やってもいいが、リファクタリングの目的としては正しくない。
- リファクタリングは、リファクタリングの前後で改善点を評価できなければならない。行が減ったのであれば、それはその分バグの潜在するリスクを減らしたと評価できる。リファクタリングの結果行数が増えるのはいけない。
- リファクタリング中にバグを見つけても、そのバグを修正すべきではない。バグが悪いのか、リファクタリングが悪いのか分からなくなってしまうため。
- Goのgo fmtは素晴らしい。
- Javaは言語レベルでDeprecatedをサポートしている点が素晴らしい。
Posture for Engineers
感想
- スピーカーは、エンジニアやりつつヨガの講師もやっているという女性。Postureは姿勢という意味。
- 技術的な内容ではないが、ヨガやっていたこともあって興味があったので、気軽な気持ちで参加した。
- トーク中にみんなで席から立って腰や肩にいい立ち方をして、思い出に残った。
内容
- 「椅子に座る」という動作自体、人間の歴史からすると最近の出来事なので、長時間使っていたら負担も大きい。
- 長時間座っていると股関節が固まってくるので、意識して1時間に1回立つようにするのが大事。
- バランスボールに座って仕事をしたり、スタンディングとシッティングを適度に織り交ぜながら仕事をするのがオススメ。
Run containerized workloads with Lattice
感想
- Lattice含めCloudffoundryあたりのこと全く知らなかったので、基本的な内容ざっと知れてよかった。
内容
メモそのまま。。。
- LatticeはCloudfoundryのサブセット。スケジューラもあり、diegoという。
- cloudfoundryはインストールしにくい。不要なのも一緒にインストールされる。だるい。
それで機能は少ないが、簡単にインストールできるlatticeが作られた。 - Latticeはパーシステントデータはサポートしていない。あくまで開発用。
- Dockerにはロードバランシングやオートヒーリングがない。
- K8sもあるが、最高ではない。単なるスケジューラに過ぎない。
Profiling & Optimizing in Go
資料
Go Debugging, Profiling, and Optimization
感想
- Goそんなに書いたことがなくてついていけない部分も多々あったけど、Goにはpprofという強力なプロファイリングツールが備わっていて、webというコマンドでプロファイリング結果を図示することまでできることがわかった。
YAPC全体の感想
- YAPCには昨年、今年と参加したが、本当に楽しかった。
- YAPCはPerlだけにとどまらない技術の祭典という感じで、本当に素晴らしいイベントだったと思う。今年で最後なのが惜しまれる。
- 普段Twitterでフォローしているエンジニアの方のトークを聞くのは本当にモチベーション上がる。
- LTではbotの話題が多かった。この辺りはこれからまだまだ面白いことやる人が出てきそうな予感がして、期待大。
- ベストトークの2位、3位はHTTP2関連だったということで、HTTP2勉強しなきゃな、と思った。
- Consulの話も随所に出てきていたっぽい。
- あらかじめ準備されていたトークだけでなく、会場で話をしたエンジニアの方のレベルの高いディスカッションの内容も伝わってきたりして、本当有難い感じだ。→OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか?
- ノベルティのサイリウム良かった。子供めっちゃ喜んでた。
