VOYAGE GROUP エンジニアブログ

voyagegroup_techのブログ
VOYAGE GROUPエンジニアブログです。

2014年04月

新人エンジニアに薦める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でメンションしてください。 

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

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

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

 

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

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

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

Permanent Link な URL

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

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

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

シンプルな ACL

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

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



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



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

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

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

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


仲間を募集してます!

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


 

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

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


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


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

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

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

などがあると思います。

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

  1. ゾーンの編集(作成, 削除)/基本的なレコードの編集(作成, 削除, 変更)ができる
  2. 本番環境の設定変更の前に、適切な検証環境でレコードの変更をテストできる
  3. 2で実施した変更と完全に同一な変更を本番環境に適用できる 
  4. 適用した変更を(出来る限り短期間で)切り戻せる
  5. 任意の時点での変更内容を後から確認できる
  6. Route53から別のDNSサーバーに移設したいとなった時に、低いコストで対応できる
  7. 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を実行して意図した結果が返ってくるかの確認)を
を作成して、合わせて利用しています。

簡単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ファイルを用意しました。
hello world
500エラーが発生するように変更します。 アクセスログにステータスコード500が出ていますね。ではこの500エラーを検知して、Slackに投稿するスクリプトを作成しましょう。
$ perl alert.pl /var/log/httpd

の実行でエラー通知が来ます。エラー通知を発見したら、後はエラーログを探って原因を特定すればよいでしょう。
WS000007

cron に登録すれば、簡単に500系エラーの監視ができるようになります。



いかがでしょうか?Slackは非常に良いコミュニケーションツールだと思います。たくさんの既存サービスと連携可能なので、ツールの切り替えにかかる時間は殆どありませんでした。まだ使っていない人は是非試してみてください。
記事検索
QRコード
QRコード