VOYAGE GROUP　エンジニアブログ : 2014年04月

2014年04月

2014年04月30日16:40

カテゴリ: 育成

新人エンジニアに薦める1冊

巷では「新人エンジニアに勧める一冊」が流行ったらしいのでVOYAGE GROUPでも聞いてみました。

▼1つだけ選ぶなら！

書籍名	薦めた人	理由	いいねした人
計算機プログラムの構造と解釈	@suzu_v	全人類が読むべき	@ajiyoshi @makoga @brtriver @hagino3000
体系的に学ぶ安全なWebアプリケーションの作り方	@ajiyoshi	体系的に安全なWebアプリケーションの作り方を学べるから	@suzu_v @makoga @brtriver
Webを支える技術 ── HTTP，URI，HTML，そしてREST	@brtriver	基礎だけどとても大事なことが学べる	@suzu_v @makoga
情熱プログラマーソフトウェア開発者の幸せな生き方	@_zoo	研鑽の大切さがわかるから	@jewel
パターン認識と機械学習上, パターン認識と機械学習下	@hagino3000	学び続ける事の必要性を、これでもかというぐらい思い知らせてくれるから	@ajiyoshi
リファクタリング―プログラムの体質改善テクニック	@co3k	コードの不吉な匂いとはそもそも何かを知って欲しいのと、現実にたゆたうあらゆるコードに立ち向かう気が沸いてくるはず	@makoga
UNIX 4.3BSDの設計と実装	@awa-vg	UNIX 系 OS のサーバエンジニアは必読。アプリケーションプログラマであっても OS の知識は必ず役に立ちます。古い分シンプルなのも○	@ajiyoshi
パターン・ランゲージ: 創造的な未来をつくるための言語	@TachibanaKaoru	ソフトウェアデザインだけでなく、全人類汎用のパターンを取り扱ってるので。
Clean Code アジャイルソフトウェア達人の技	@jewel	それなりのコードを書こうという気持ちになる
リーダブルコード――より良いコードを書くためのシンプルで実践的なテクニック	@sys_cat	個人的に新人時に読みやすかった
お〜い!竜馬	@masakiMatsumoto	不可能なことは無く、新しい時代を作っていくという気持ち	@ajiyoshi

▼無制限かつ無秩序にオススメする編

オススメ	理由	いいねした人
ハッカーと画家コンピュータ時代の創造者たち		@ajiyoshi @makoga @_zoo
Joel on Software		@ajiyoshi @makoga
認証技術パスワードから公開鍵まで	いまどき自前で認証機構を拵える時代でもないが、なぜそういう仕組みになっているのかを知るのは重要だし、「どういう脅威があって、どういう対策ができるか」という普遍的な考え方が身につくと思う。パスワードの選び方なんかもあるよ
めんどうくさいWebセキュリティ	Web セキュリティは面倒くさいものだということを知ってほしい。最近の若者はいきなり面倒くさい中に放り込まれていると思うので、どうして面倒くさいのかも知ってほしい
プログラミング作法	(家帰って読み返さないと)
プログラミングErlang	改訂版が出るまで待ったほうがいいかもしれないが。	@ajiyoshi
ご冗談でしょう、ファインマンさん〈上〉, ご冗談でしょう、ファインマンさん〈下〉		@makoga
オープンソースソフトウェアの育て方	OSS と冠してはいるが、いまどきの pull request を利用した開発スタイルとか、エンジニア的チームの作り方とか参画の仕方とか、 OSS に関わっていなくても得られるものは多い。けど OSS に関わっていない人には勧めにくい……
詳解UNIXプログラミング第3版	古文書のたぐいだけど、枯れたツールの水平思考は悪くない。	@ajiyoshi
UNIXという考え方―その設計思想と哲学
ビジネスモデル・ジェネレーション	フリーミアム、ロングテール、プラットフォーム, etc. といったビジネスのパターンを学ぶ事ができる。GoogleやSkypeといった普段使っているサービスがどのようにして利益を生み出しているかを知る事ができる。

集計してみると、やっぱりなというVOYAGE GROUPらしいラインナップでした。

[PR]
VOYAGE GROUPでは仲間を募集しています！
上記本を読んでる人はもちろん、読んでない人も興味があれば応募ください。
気軽に #ajiting してみたい人は上記の誰かにtwitterでメンションしてください。

voyagegroup_tech

2014年04月21日19:45

カテゴリ

こんにちは！ (株)Zucks で Zucks Ad Network というアドネットワークシステムを開発・運用している @brtriver です。

先週末に Symfonyユーザー会主催の Symfony 勉強会 #9 がフォトクリエイトさんのご協力のもと開催され、"管理画面Webアプリケーションのアクセスコントロール" というお題で話をしてきました。スライドは既に公開していますが、内容について補足しつつ "運用しやすい管理画面" について書いてみたいと思います。

管理画面のアクセスコントロール from Masao Maeda

運用しやすい管理画面とは

今回いいたかったことをまとめると以下の2点になります。

URLに必要な情報が含まれていること
アクセスコントロール (ACL) がシンプルなこと

Permanent Link な URL

運用のしやすさの一つは "何かあったときに調査しやすいかどうか" だと思います。
そのためには、問題が起きた場合にそのURLを共有してもらえれば同じ画面を見れるというのは地味ですがとても有効です。

"〇〇のアカウントでログインしてもらって、△△に遷移して、XXを選択してもらったときの画面なんですが..."

という会話をしないと見れないのは運用しづらいですよね。

シンプルな ACL

また、ACL の設計は管理画面ではとても重要ですし、ミスすると即事故になる可能性があります。
取得するデータの内容だったり、見せ方だったりロールによって細かく変わるというのはよくある話です。
しかし、それをそのまま深く考えずに実装していくと、修正がとても怖くて触れないロールごとの条件分岐地獄になる可能性があります。

たとえば、各所で権限チェックを行うようなコードになってしまうパターンです。

管理画面のアクセスコントロール from Masao Maeda

今回は Controller や View で権限チェックをせずに、Routing部分から Requestを受けた段階で権限をチェック するようにしました。そして、Controller と View は権限ごとに完全に分離しました。

管理画面のアクセスコントロール from Masao Maeda

Symfony2 を利用しているので、フレームワークで用意されている Security 機能を薄めに活用しつつシンプルにルーティング部分で ACL を行うようにしました。

プロダクトは日々進化を遂げており１日に５回デプロイするなんてことも普通にありますが、権限周りで事故を起こさずにロール毎に日々管理画面を運用できています。

また、シンプルな ACL はエンジニアの健康を維持するためにも必要だなと思っています。健康と睡眠大事です。

今回も勉強会は本編だけでなく懇親会も 23:00 まで熱い会話で盛り上がっていました。
次回は3ヶ月後ぐらいを予定(?) しているので興味がある方は是非参加してみてください。

仲間を募集してます！

VOYAGE GROUPでは仲間を募集しています。興味がある方はとりあえず天ぷら食べながら #ajiting しましょう！お気軽に twitter でメンションください！

voyagegroup_tech

2014年04月10日12:23

カテゴリ: programming; ruby

Route53をbind形式のzoneファイルで管理するツール, bind2route53を作成して公開しました。

こんにちは。
VOYAGE GROUPのシステム本部でインフラエンジニアとして働いている @s_tajima です。

DNSサーバーとしてRoute53を利用しようとした場合、
登録されたゾーン(HostedZone)やレコードをどのように管理するかというのに
悩んでいる方々も多いと思います。

特にVOYAGE GROUPでは、
現在約100ゾーン, 約2500レコード
というとても多いレコードを管理しているのでとても重要な問題です。

一般的にすぐに思いつく管理の手段としては,,

Management Consoleを操作してゾーン/レコードを管理する。
AWSが提供するSDK等を使い、Route53のAPI(ChangeResourceRecordSets等)を叩く。
既存のRoute53の管理ツール(RoadWorker等)を使う。

などがあると思います。

これらの手段を選択する前に、Route53を管理する上で、
どのような用件が満たされていると良さそうかを考えてみましょう。

ゾーンの編集(作成, 削除)/基本的なレコードの編集(作成, 削除, 変更)ができる
本番環境の設定変更の前に、適切な検証環境でレコードの変更をテストできる
2で実施した変更と完全に同一な変更を本番環境に適用できる
適用した変更を(出来る限り短期間で)切り戻せる
任意の時点での変更内容を後から確認できる
Route53から別のDNSサーバーに移設したいとなった時に、低いコストで対応できる
Route53独自の機能(ALIASレコード等)を利用できる

と、このあたりでしょうか。

具体的な説明は割愛しますが、
検証の結果先に挙げた3つの手段では
これらの用件を満たすことは不可能/工夫が必要だということがわかりました。

このような背景から上記の用件を実現できるツールとして,
bind2route53(https://github.com/voyagegroup/bind2route53)を作成しました。

bind2route53_fig1

このツールがどのような機能をもっているかを簡単に説明すると、

・bind形式のzoneファイルをCloudFormationのTemplateに変換する。(convert_zonefile)
・Route53上に、ゾーンを作成する。(create_hostedzone)
・CloudFormationに、Route53を管理するためのStackを作成する。(create_hostedzone_stack)
・CloudFormationのStackを更新し、Route53のゾーン/レコードの編集をする。(update_hostedzone_stack)

というシンプルなツールとなっています。
このツールがどのように上記の用件を満たしているのかを説明すると、

1. ゾーンの編集(作成, 削除)/基本的なレコードの編集(作成, 削除, 変更)ができる
上記の機能を見ればこの用件を満たしていることはわかると思います。

2. 本番環境の設定変更の前に、適切な検証環境でレコードの変更をテストできる
上記の機能を実施する際, 設定ファイルにIAMの鍵を複数設定し、どの鍵を利用するかを指定します。
検証環境用の鍵と本番環境の鍵を登録することで、事前に検証環境でテストをすることができます。
※尚、検証環境と本番環境は、別のAWSのアカウントを用意することを前提としています。

bind2route53_fig4

3. 2で実施した変更と完全に同一な変更を本番環境に適用できる
検証環境に対して実行したコマンドを、
環境の部分だけ本番環境とすることで同じ内容が本番環境に適用されることが保証されます。

4. 適用した変更を(出来る限り短期間で)切り戻せる
bind形式のzoneファイルをバージョン管理(gitやsvn)しておき、
設定に不備があった場合にはzoneファイルを切り戻し(git checkoutやsvn revert)して
再度CloudFormationに適用することで、切り戻しが行えます。

5. 任意の時点での変更内容を後から確認できる
4に記載した通り、zoneファイルをversion管理下に置くことで変更の履歴を閲覧できます。

6. Route53から別のDNSサーバーに移設したいとなった時に、低いコストで対応できる
bind形式のzoneファイルを管理するので、一般的な別のDNS管理サービスへの移設コストは低いと言えます。
(Route53もそうだが、bind形式のzoneファイルをimportする機能を提供するサービスが多い。)

7. Route53独自の機能(ALIASレコード等)を利用できる
例外的に、zoneファイルに独自のシンタックスを記述することで
Route53独自の機能を利用できるような機能を提供しています。

使い方についての詳細はこちらに記載してあるので参考にしてぜひお使いください。
以上、bind2route53の紹介でした。

#====================================

※尚, VOYAGE GROUPでの現在の運用環境では
bind2route53をラップするスクリプト
(convert_zonefile -> update_hostedzone_stackをコマンド1つで行う等)や、
DNSの設定変更をした際に、その変更が正しくできているかを確認するツール
(内部的にはdigを実行して意図した結果が返ってくるかの確認)を
を作成して、合わせて利用しています。

voyagegroup_tech

2014年04月08日15:00

カテゴリ

簡単500系エラー監視 in Slack

こんにちは、RPAの関口です。前回はモデルとして登場（【番外編】バレンタイン緊急企画: エンジニアはPARCOさんへゆけ）させて頂きましたが、今回は執筆者です。プライベートの目標進捗については芳しくありませんので触れないでやって下さい (泣

さて皆様、エンジニア間での情報共有には何をお使いでしょうか？簡単な依頼はSkype、障害アラートが飛んでくるのはメール、開発の進捗はGitHubのissueで管理し、MTGの議事録はGoogle Docsなど複数の手段を併用しているのでは無いでしょうか？個人宛てSkypeに来てしまった依頼なんかはチーム全体として何が起きているのか把握しづらくなりますし、複数のコミュニケーション手段を使っているせいで「あれどこにいったっけ？」ということも頻繁に起きます。

そんな時に役立つのがSlack: Be less busy とかIdobata といった、情報を1箇所にまとめられるツールです。RPAではSlackを利用しております。GitHubと連携してissueの更新をSlack にポストしたり、Google Docs のファイルをSlackから検索することもできます。またIncoming WebHookを使えば独自のHookも作れますので、例えばデプロイスクリプトの完了時にSlackに投稿することも可能です。

今回はそのIncoming WebHookを使って、500系のエラーが発生したらSlackに投稿する、という簡単スクリプトを作りたいと思います。

仮想マシン上に立ち上げたサーバーに下記のようなphpファイルを用意しました。