mixi engineer blog

ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

伝承進化し続ける技術イベント: git challenge開催記念インタビュー

こんにちは、ミクシィグループ 人事部です。

今回で第6回目*1を迎える、競技型技術イベント「git challenge (ギット・チャレンジ)」開催にあたり、運営に携わるエンジニア社員の国分さんと轟さんにお話を聞いてきました。
過去5回の大会を振り返るとともに、git challengeへの想いを語っていただきます。 #mixi_git

 

f:id:mixi_engineers:20170727135539j:plain 

続きを読む

新卒研修受講レポート~テスト編~

はじめまして、17新卒エンジニアの村上と林です。

今回は「テスト」という「プログラムが正しく動作しているかチェックするためのプログラム」についての研修を受けたので、まとめていきたいと思います。

 

本研修の内容は以下のようなものでした。

・テスト/設計についての簡単な講義

・ペアプログラミングでの実習

  • 車窓からのTDD
  • 円の面積を求めるプログラムをTDD
  • emailアドレスの正誤判定プログラムをTDD

 

テストについての簡単な講義

 

テスト研修の目的

まず、なんでこんな事やるの?という事で、研修の目的について述べたいと思います。

研修の目的は「良い設計を覚える」、これだけです。

 

良い設計ってなんなの?

そこで、良い設計とは?となると思います。

疎結合?可読性?

色々あると思いますが

「経営的な要求・条件に応えられること」です!

経営判断としてスピードが求められる場合には可読性よりも開発スピードを優先する場合もあります。良い設計に重要なものはその時の状況によって変わるということです。

 

しかしながら、突然のメンバー変更や仕様変更などが往々にして発生し、保守しづらいコードでは何をしているのかよく分からなくなるため、結果的に保守しやすい設計の方が(引き継ぎなども含めて)開発スピードが早くなります。

なので今回の研修では「保守のしやすさ」に焦点を当てます。

 

いい(保守しやすい)設計方法

保守しやすい設計方法として、テスト駆動開発(test-driven development:TDD)を利用します。この手法では、大きく3段階の手順を踏みます。

  1. テストを書く
  2. テストを失敗させる
  3. 実装してテストを成功させる

この3つの手順を実施することにより保守しやすい設計になります。


TDDのメリット

メリットは以下の3点です。

・テストを先に書くので、テストしづらいコードを書けない

・テストしやすいコードは疎結合で副作用もなく分岐も少ない

・この作業をやっていくと自然に保守しやすい設計になる

 

ペアプログラミングでの実習

ここまでの講義内容をペアプロで実践しました!

(※ペアプログラミング: 2人でプログラミングすること。常に片方がレビューをやっているので様々なメリットがある)

f:id:mixi_engineers:20170510162530j:plain

車窓からのTDD

「車窓からのTDD」はweb上に公開されており、内容としても簡単なのでTDDを体験してみたい方はリンク先を確認してみてください!

http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf

 

「車窓からのTDD」には対話形式でTDDのやり方が書かれており、手順通りに進めていくだけで良いため、手始めのTDDの理解にとても役立ちました。

 

「車窓からのTDD」はスタックを構築するだけの簡単な内容で、上記したTDDの流れの通り、テスト作成し失敗、実装、再度テストを実行させ成功、のサイクルで行います。これはTDDでは基本の流れになります。今回の研修では、各自経験のある言語(RubyやPythonなど)で作業を進めていきましたが、どの言語でも基本の流れを抑えれば大丈夫です。

 

テストを書いてから実装をするので、実装の目的が明確になることで無駄なコードが減り綺麗なコードになると感じました。


円の面積を求めるプログラムをTDD

この課題では、「標準入力経由で円の半径が渡されるので、円の面積を求め四捨五入して整数に丸める」というプログラムを書いていきました。

入力が外から入ってくるため入力値に対するテストが必要になります。

この課題の採点が一回しか行われないという条件だったため、絶対に正解するように多くのテストを書きました。

(テストケースをたくさん書いて置くことで途中でコードの間違いを素早く見つけることができました。間違いなく実装するという点においてもすごくテストが役に立ち、重要なんだと実感しました!)

 

また、今回の課題でのポイントは標準入力でデータが渡ってくるという点です。テスト(今回の場合ユニットテスト)はロジックだけをテストしたいので依存性がないものが理想です。標準入力に依存しないように、スタブやモックオブジェクトで切り離す方が良いでしょう。

 

emailアドレスの正誤判定プログラムをTDD

「emailアドレスが"RFC5312 addr-spec"の部分的な仕様として正当なものであればok、違えばng」のテストを作成しました。

今回の場合、大量のテストケース(ngになるメールアドレス、okなメールアドレス)が必要になります。

なので、どのテストケースで失敗したかを分かりやすくする工夫が必要でした。

 

テストの速度は上げつつ、どこで失敗したかを判別したいのですが様々な方法があるようです。Rubyの黒魔術的な方法もあるようですが、後日調べたところこのような書き方もあるようです。

qiita.com

 (テスト書いててどんなテストケースあるかなってなったとき、キレイに書いてると「このケースもあったな」となりやすいので、保守性と速度が確保されると感じました)

 

まとめ

今回の研修ではテストの重要性について学びました。

保守しやすい設計で、引き継ぎの方や後輩達に、先輩はいいコード書くやろ?ってドヤ顔しましょう!!!!

新卒研修受講レポート~セキュリティ編~

こんにちは。2017年新卒エンジニアの追田と服部です。

本記事では、4月におこなわれた新卒エンジニア向けのセキュリティ研修の大まかな概要や感想を受講者の立場からお伝えしたいと思います。

講師はXFLAG事業本部 たんぽぽGの亀山さんです。

 

内容

研修は以下の3部構成で実施されました。 

  1. セキュリティの必要性や脆弱性とその対策についての説明
  2. WebGoat(研修用やられサイト)を用いた実習
  3. スマートフォンゲームのチート事情についての解説


1. セキュリティの必要性や脆弱性とその対策についての説明
まず、企業が情報セキュリティ上の過失によって個人情報漏洩などの事故を起こしてしまった場合、どのような影響が考えられるでしょうか。
その企業の信頼の低下やイメージダウンを招いてしまうことはもちろん、それに伴う業績悪化や対応費用によって数百億円規模の損失を計上してしまう場合もあります。

本研修では過去に発生した実際のセキュリティ事故の事例を知るとともに、具体的な脆弱性の対策手法について学びました。

脆弱性の攻撃手法で最も有名なものと言えばSQLインジェクションが思い浮かぶかと思いますが、ウェブアプリケーションエンジニアが気を付けるべき脆弱性はこれ以外にも数多くあります。
IPA(情報処理推進機構)が公開している「安全なウェブサイトの作り方」によると、攻撃手法は以下の11種類に分類され、それぞれについて適切な対策をとる必要があります。

1. SQLインジェクション
2. OSコマンド・インジェクション
3. パス名パラメータの未チェック/ディレクトリ・トラバーサル
4. セッション管理の不備
5. クロスサイト・スクリプティング
6. CSRF(クロスサイト・リクエスト・フォージェリ)
7. HTTPヘッダ・インジェクション
8. メールヘッダ・インジェクション
9. クリックジャッキング
10. バッファオーバーフロー
11. アクセス制御や認可制御の欠落

次のセクションでは、研修用に用意された実際のWebサイトを攻撃することを通してこれら脆弱性を対策することの重要性を学んでいきました。

2. WebGoat(研修用やられサイト)を用いた実習
ここでは、WebGoatと呼ばれる練習用Webサイトを攻撃することで前述の様々な種類の脆弱性について手を動かしながら学びました。

f:id:mixi_engineers:20170510162020j:plain

攻撃手法についてですが、例えばBurp Suiteという脆弱性診断ツールを用いるとHTTP通信のキャプチャやリクエスト内容の書き換えを簡単に行うことができます。※悪用は厳禁です!

3. スマートフォンゲームのチート事情についての解説
ここからは、講師の亀山さんの専門分野でもあるスマートフォンゲームにおけるチートに関するお話を聞きました。
日本最大級のユーザー数を誇る、スマホアプリである「モンスターストライク」のチート対策について、実際にセキュリティエンジニアからお話を聞くことができるのはミクシィの研修ならではのことです。

資料の一部はXFLAGサイトのブログでも公開されていますので、興味のある方はぜひご覧ください。
スマートフォンゲームのチート事情(@ITセキュリティセミナー)|XFLAG ケタハズレな冒険を。
 

当日の様子(感想) 

当日印象的だったハプニングがあります。この研修ではWebGoatを使って脆弱性のあるWebサイトを攻撃してその防御手段を学ぶのですが、研修用のサーバがトラブルによってうまく動かなくなってしまったのです。

 

そんな時に同期がDockerのWebGoatイメージがあることを発見して、それぞれのPCにそのイメージを用いたDockerコンテナを立てることを立案しました。新卒同士助け合いながらそれぞれのマシンにWebGoatのDockerコンテナを立てて無事にトラブルを乗り切りました。その時は同期のチームワークを強く感じ、トラブルを通じて研修の士気が高まりました!

f:id:mixi_engineers:20170510162053j:plain

1.セキュリティの必要性や、脆弱性とその対策についての説明

 

Webサイトを作る上で脆弱性を意識して開発することの重要性はわかっていたつもりでした。しかし、これまでに起きたセキュリティ事故の事例やその被害規模を紹介されると、認識が甘かったなと感じると同時にどのようにすればセキュリティ事故を防ぐことができるのか俄然関心が高まりました!

中でもセキュリティ事故と株価の関係が紹介された時が一番盛り上がっていましたね(笑)。

 

2.WebGoat(研修用やられサイト)を用いた実習

 

Webサイトを攻撃するというのは本当なら犯罪ですが、今回はWebGoatという攻撃用のWebサイトなので安心して攻撃することができました(笑)。

このWebGoat、攻撃手法ごとに問題を解いていくようにできており、その問題量も膨大で研修時間で全て解くことは不可能なので、私は、

 

1.SQLインジェクション

2.XSS(クロスサイトスクリプティング)

 

の2つに絞って問題を解き進めました。

 

どちらも有名な攻撃手法ですが、実際に攻撃者側に立ってみて攻撃してみると、意外と簡単に情報の入手や改ざんができてしまうものだと感じました。

 

攻撃手法に詳しくなくてもネット上の情報があれば、意味を理解していなくても簡単にWebサイトを攻撃できてしまいます。攻撃が簡単にできてしまうからこそ、常に防御のことを考えてアプリケーション開発をしなくてはいけないのだなと改めて感じました。

 

3.スマートフォンゲームのチート事情についての解説

 

Webサイトに対する攻撃は多少なりとも知っていましたが、昨今のスマホゲームのチート事情がどうなっているのかは恥ずかしながら知りませんでした。

 

しかし、チートに利用できるツールが出回っており、メモリの値を書き換えたり通信内容を改変することによって簡単にできてしまうことがわかりました。ツールさえあれば中学生でも簡単にチートすることは可能です。だからこそ、しっかりと対策を練らなければいけないのだなと痛感しました。

 

ゲームの不正行為で狙われやすい箇所はおおまかに、

1.メモリデータ

2.ストレージデータ

3.ロジック

4.通信

5.操作

と分類され、データ改変や操作の自動化などが行われる可能性があります。

 

例えば、メモリデータの改変はチートでもメジャーな手法なのですが、今回弊社のモンスターストライク(以下、モンスト)を題材に考えてみます。

 

モンストでは、ガチャを引く際「オーブ」というアイテムを使用します。現在10個のオーブを所持しているとします。

不正ユーザはこのメモリ上の10という数値をプロセスメモリエディタというツールを使って数値を999に改変し、オーブを不正に増やそうとするかもしれません。

 

では、この場合どのような対策が考えられるでしょうか?

 

-メモリ上の値を暗号化する

-計算に利用する数量をクライアント側に持たない

 

など、考えられる対策はいくつかあります。

 

この時大切なのは、選んだ対策はそもそもの目的との折り合いがつく対策であるのか、などを考えしっかりと吟味することです。

 

また、サーバの処理はほぼ手出しができないので、近い将来クラウドゲーミングのように処理の大半をサーバ上で行うようになれば昨今のチート手法はほぼ無意味となるかもしれません。

 

しかし、現状はスマホ側でゲーム処理を行うケースも少なくないため、これらのポイントを押さえた対策が必要となります(操作の自動化は厳密にはチートではないが不正行為を目的に行われる事もある)。

 

また開発時は面白さや快適さを重視するので、Webアプリほどセキュリティに意識が向かないことが課題として挙がっていたことに納得すると同時に、難しさも感じました。

ゲーム開発者としてユーザに対してワクワク感を提供することを第一に考えたいけれども、そうするとセキュリティがおろそかになってしまうというジレンマは辛いものです。

 

まとめ

今回の研修では座学のみならず、実際に攻撃してみることでWebアプリを開発する上でのセキュリティの重要性を実感することができました。

 

また、昨今巷を賑わせているスマホゲームのチート対策も学ぶことができます。

アプリからゲームまで様々なセキュリティを取り扱う研修はなかなか珍しいのではないでしょうか。

 

Amazon EC2 リザーブドインスタンスの利用状況をDatadogで監視する(AWS Summit Tokyo 2017 で発表してきました)

はじめまして。北村です。
 
先日行われた AWS Summit Tokyo 2017 で、Datadog 様の EXPO セッション枠の一部を頂いて SNS「mixi」における Datadog 活用事例について紹介させていただきました。

speakerdeck.com

今回は、その発表の中で紹介させていただいた EC2 リザーブドインスタンスの管理・購入を支援する以下の自作ツールについて紹介をしたいと思います。

github.com

ツールの概要

先にツールの概要を解説しますと AWS の API から得られた EC2 インスタンスの稼働状況とリザーブドインスタンス契約情報を集計し

  • 稼働中のインスタンス数
  • 有効なリザーブドインスタンス数
  • オンデマンドインスタンス数
  • 未使用状態のリザーブドインスタンス数

以上の推移を、Datadog 上でリアルタイムで可視化するというインスタンス集計プログラムとなります。

ここで、Datadog について簡単に紹介しますと「クラウド型のサーバ監視ツール」となっております。AWS 移行のタイミングで SNS「mixi」には導入しており、日々活用させていただいています。

www.datadoghq.com

Datadog は「多機能かつ柔軟なグラフ機能、ダッシュボード機能を持つこと」に加えて「カスタムメトリクスと呼ばれるユーザ定義のメトリクスを利用することで、自由な数値を簡単に可視化ができること」が非常に魅力的なサービスです。
今回のツールでも、その機能を利用し、集計した各数値をカスタムメトリクスで Datadog に送信することで可視化を実現しています。
 

f:id:mixi_engineers:20170612112154p:plain

 
Datadog で描画したサンプルグラフ(数値はダミーです)がこちらとなっています。
 

f:id:mixi_engineers:20170608135048p:plain

これは、t2.medium のインスタンス数の推移を可視化させた例となっており、以下の推移が分かると思います。
  • Running Instances (稼働中のインスタンス数)
  • Reserved Instances(リザーブドインスタンス数)
  • Unused Reserved Instances(未利用状態のリザーブドインスタンス数)
  • On-demand Instances(オンデマンドインスタンス数)
グラフ中央付近のタイミングで13台のリザーブドインスタンスを購入しているのですが、それによって各値が変動していることも分かると思います。

ツール作成のモチベーション

AWS で EC2 を利用されている方ならば、リザーブドインスタンスの利用検討を少なからずしているのではないかと思います。
オンデマンドインスタンスをリザーブドインスタンスに切り替えることで、最低1年の利用コミットが発生してしまいますが、オンデマンドインスタンスよりも最大75%引きの値段でEC2を利用することができるからです(詳しくは AWS のサイトを参照していただければと思います)。
 
SNS「mixi」は長年オンプレミスで運用してきましたが、2015年よりほとんどのサーバを AWS に移行を行いました。
オンプレミスからの移行ということもあり EC2 が非常に多く、リザーブドインスタンスを積極的に活用することで大きなコスト削減を実現しています。
 
しかしながら、移行が進むにつれてインスタンス数が増え、インスタンスタイプも増えてくるとリザーブドインスタンス契約の管理が煩雑になってきて
  • 一体どれだけのオンデマンドインスタンスが存在しているのか?
  • リザーブドインスタンス契約数は適切であるのか?
  • 余っているリザーブドインスタンスはないのか?
を把握するのが苦しくなってきました。
 
中には AutoScaling であったり、平日昼間、逆に夜中にしか稼働させていないサーバも混在しており、1日の EC2 の台数の上下が激しくなっています。
これもリザーブドインスタンス契約の判断を複雑にしています。
 
リザーブドインスタンスの利用状況はAWSコンソールの「EC2レポート」を参照すると把握することができるのですが、以下のデメリットがあります。
  • リアルタイムではない(1〜3日の遅延)
    以下は「EC2レポート」で直近のインスタンス使用状況を表示させた例となっています。直近の2日間は値が完全に取れていないことが分かります。このため、リザーブドインスタンスの過不足状態を確認するまで時間がかかってしまいます。

    f:id:mixi_engineers:20170612113459p:plain

  • 時間毎の詳細な利用状況が分からない(利用状況が1日でまるめられてしまう)
    • なので、未使用リザーブドインスタンスがあったとしても、まるまる1日余っているのか、一定時間だけ余っているのか分からない状態になっています
    • AWS Detailed Billing Reports を参照すると分かりますが、別途集計処理が必要になってしまいます
 
そこで、AWS の API よりインスタンスの利用状況を取得、集計し、リアルタイムで Datadog で可視化してしまおう!というのが、今回の紹介させていただいたツール作成のモチベーションでした。
 
このツールを活用することで SNS「mixi」では複数のリザーブドインスタンス契約の管理に加え、リザーブドインスタンス契約判断を行っています。

おわりに

AWS Summit Tokyo 2017 のセッションでは以上のツール紹介に加えて、なぜ Datadog を選択し導入したのかについても紹介させていただきました。
当日は多くの魅力的なセッションがあるなか、足を運んでいただいた方もいらっしゃり、大変ありがたかったです!
 
また、最後になりましたが Datadog 様には、このような機会を与えてくださり、ありがとうございました。Datadog 様からは Datadog ロゴが刺繍されたパーカーをプレゼントしていただきました。American Giant というサンフランシスコのアパレルスタートアップ製のパーカーで自分も大好きなメーカーです。
セッション当日は、嬉しくて、パーカーを着るには暑い日でしたが汗をかきながら着用して発表させていただいたのもいい思い出です。
 

f:id:mixi_engineers:20170608135654j:plain

 
最後まで読んで頂きありがとうございました!

PyCon JP 2016 にダイヤモンドスポンサーとして参加してきました。

はじめまして、株式会社フンザの尾関と申します。

普段はチケットキャンプのサーバサイドをPython/Djangoで開発しています。
趣味はドローンでの空撮です。

エンジニアブログですが、技術的な話は特にありません。すみません。

 

9/21, 9/22の2日間、PyCon JP 2016という日本最大のPythonistaが集うカンファレンスに参加してきました。

 

当社では創業時からチケットキャンプのサーバサイドをDjangoで開発しており、我々のビジネスができているのも全てPythonという存在のおかげ!という思いもありまして、その恩返しとしてダイヤモンドスポンサーとして出資させていただきました。

 

個人的には、2013年と2015年に一般で参加したので雰囲気は分かっていましたが、今回はスポンサーとしてブースを出す!ということでまた違った視点から参加できました。

 

もちろん、ブースを出すからには、フンザという会社を知ってもらいたい!チケットキャンプを知ってもらいたい!いい人がいれば採用につなげたい!という目的があり、それを全面に打ち出すブースづくりを心がけました。

↓設営の様子

f:id:mixi_engineers:20160929190420j:plain

 

このあたりは、我々のようにイベント慣れしていない担当者が、初めてブースを出すことになった場合の参考に少しでもなればいいなと思って書いています。

と言っても、我々も反省点だらけでまだまだ改善の余地があるので、来年またスポンサーとして出展できるのであれば、もっと良い形にできるだろうと思っています。

ブースでやったこと 

f:id:mixi_engineers:20160929192200j:plain

話さなくても事業・社内の様子が分かるように

実際に開発者が使っている32インチ4Kのディスプレイを2台持ってきて、片方はTVCMの動画を流すことで事業の紹介と、もう片方は社内イベント・社内風景などの様子も流して、会社全体の雰囲気が伝わるように心がけました。

けっこう立ち止まって見てくれる方もいらっしゃったり、実際にお話したときに「楽しそうな職場ですね」と言って頂けたりしたのでこれは見る側としても良かったんじゃないかと思いました。

ブースに来てくれた方にプレゼント

これはやっぱりノベルティですね。今回は奮発してTシャツとステッカーを配りました。1日目に配ったものを2日目に着てくれていた方もいて、配っているこちら側も嬉しい気持ちになれました。

さらに、『積極採用中!』と記載された名刺サイズのカードも沿えて配りました。これは『よくある採用のチラシを配っても、正直あまり見られない』と親会社からアドバイスをうけて作りましたが、配る方も配りやすく、もらう方も負担にならないのでかなり良かったんじゃないかと思いました。

実際に渡したデザインがこちらです。必要なメッセージだけに絞っています。

f:id:mixi_engineers:20160930170054p:plain

キャラクターで認知してもらう

他の企業を見ていると、特に、モノタロウさんはすごく良く出来ていて、というかモノタロウ侍のマスコットだけで、参加者の心を鷲掴みにしていましたね。やっぱかわいいゆるキャラはみんな好きですよね。

去年のPyConでも人気者でしたし、当然今年もモノタロウ侍が会場に来ることは分かっていたので、我々も負けじとチケットキャンプのマスコットであるチケキャン犬というキャラクターでアピールしました。

 

モノタロウ侍とのコラボ。チケキャン犬の彼ももちろんエンジニアです。

現在はもう契約上、動画は載せられませんが、、実はこれ、小島瑠璃子さんがCMで実際に着ていた衣装です。なんだか台無しにしてしまった気もするので、ファンから怒られないか心配です。気になる方はググってください

PyConJP2016に参加されている方への印象

ありがたいことにそんなブースに足を止めてくださった方も多く、様々な方とお話させていただきましたが、今年は思った以上に学生さんが多い印象でした。

聞けば、大学の研究で機械学習を使っていて、それをPythonで書いているという方の多いこと多いこと!

去年参加した時も、機械学習系の方が多い印象でしたが、今年はさらに多く、また傾向としては『機械学習』がメインの研究テーマというよりも、何か別の研究テーマがあって、その精度を上げるために機械学習を用いているという方が多く、かなり実用的なところで使われているんだなぁと関心しました(小並感) 

一方、アプリケーションエンジニアとしてPythonを使っている企業というのは日本ではまだまだ少ないなぁという印象でした。

弊社の発表 

2日目にジョブフェアというセッションがあり、お昼ごはんを食べながら企業の話を聞く機会がありまして、そこで弊社CTOの酒徳もパネルディスカッションに参加しました。

f:id:mixi_engineers:20160930141548p:plain

企業のブースで直接話を聞くのは緊張するけど、企業側の話を聞きたいという方にとってはすごくいい機会になりますね。

 

また、弊社エンジニアの小松もLTに登壇しました。こちらは動画・資料も公開されています。 

www.youtube.com

 

2日目のLT終了後、プレゼントのコーナーがあり、受け取ると景品がもらえるカラーボールを弊社の小松 チケキャン犬くんが頑張ってたくさん投げていました。受け取れた方、おめでとうございます。 

f:id:mixi_engineers:20160930144544p:plain

まとめ&所感

Everyone's different, all are wonderful.「みんなちがって、みんないい」

今年は上記のテーマで開催されたPyConJPでしたが、実際に業務でPythonを使っている身としては、こういうコミュニティを通して知り合いを増やし、楽しく仕事や相談の出来る仲間が増えるといいなと思っていまして、その受け皿としてこのコミュニティはとても居心地がよく、今後もPyConJPに参加していきたいなと思った所存でございます。

 

最後に 

最後まで読んで頂き、ありがとうございました。

 

株式会社フンザはPythonエンジニアを大募集しています。

もし興味がありましたらご連絡ください!

 

ノハナ開発品質向上合宿を行いました

こんにちは、side_tana です。まずは画像を見ていただきたいのですが、こういった活動を行ってきました。

f:id:mixi_engineers:20160329123640j:plain

最高ですね。ノハナでは 3月16日から18日にかけて、湯河原温泉のおんやど恵さんで開発品質向上合宿を行ってきました。

開発品質向上合宿とは

ソフトウェア開発を行う中で様々な課題と向き合う必要があります。例えばテストが薄い箇所の改善や古くなったドキュメントの整理、短期的な課題解決のため少々強引に変更を加えられた箇所の修正といった課題です。しかしながら、これらの課題と並行して日々の運用や機能追加といった業務をこなす必要があり、多くの場合短期的に優先度の高い運用や開発業務が優先されることになります。その結果として、開発に関わる困難に取り組む時間は限られてきます。

そこでノハナでは、エンジニア開発品質向上合宿という形でそれらに集中できる場所と時間をつくってみました。

進行

f:id:mixi_engineers:20160329120135p:plain

会社で開発合宿を企画するのは意外と労力がかかります。企画における労力を圧縮するため、今回は

  • ミーティングはキックオフと合宿後の振り返りのみ
  • あとはSlack中心に進め、決まったことをtrelloでカードにし、担当者をアサインする

といったアプローチをとりました。とはいえ宿や施設の調整・経路の確保など、事前の作業が多いものは負荷が高くなりがちなので、そのあたりは今後改善が必要といえます。

宿決め

いくつかの宿をリストアップし検討したのですが、今回はおんやど恵さんを利用させていただきました。ポイントとしては

  • 開発合宿プランがある
  • 無線LANが利用できる
  • 机と椅子が利用できる
    • 座敷での長時間作業は結構つらい
  • 温泉が深夜まで利用できる

といったところになります。コンビニまでの距離(徒歩15分弱)が少し気にかかったのですが、おんやど恵さんの食事が非常に豪華だったため、間食などのためコンビニに行くということはほとんどなく、問題にはなりませんでした。

www.onyadomegumi.co.jp

様子

f:id:mixi_engineers:20160329123846j:plain
初日は新宿駅に集合

f:id:mixi_engineers:20160329123714j:plain
ロマンスカーで小田原まで移動中の様子

f:id:mixi_engineers:20160329123948j:plain
宿へ到着

f:id:mixi_engineers:20160329123718j:plain
作業スペースとしてお借りした会議室はこんな感じ

f:id:mixi_engineers:20160329123726j:plain
初日の夕食(これでも一部です!)

f:id:mixi_engineers:20160329123722j:plain
二日目の夜は懇親会をしました。エンジニアの懇親会ですからやることといったらLTです。

f:id:mixi_engineers:20160329124202j:plain
最終日はチェックアウト後、小田原駅まで戻り貸し会議室で作業を続けました。

まとめ

日々の業務から離れ、割り込み作業の発生しにくい環境をつくることにより、

  • リファクタリング
  • テストの拡充・CIの追加
  • 開発ツールの更新とそれに合わせた社内ライブラリのメンテ
  • ドキュメント整理

といった作業に集中して取り組むことができ、当初の目標だった「開発品質の向上」「継続的に改善をしていくための土台作り」に対して一定の成果を得ることができました!

おわりに

f:id:mixi_engineers:20160326164045j:plain
合宿での思い出はフォトブックに!

ノハナでは一組でも多くの家族に笑顔を届けるために困難に立ち向かうエンジニアを募集しています!

Android・iOSエンジニア【Android・iOSエンジニア】さらなる飛躍のための自社サービスのグロースハック、新規事業の創造に興味あるスマホアプリエンジニア募集!!

Apple IPv6審査対応 NAT64/DNS64環境構築について

こんにちは、arukasaです。

今回IPv6 (NAT64/DNS64) のWi-Fi環境構築という貴重な経験をしましたので、情報共有を兼ねて寄稿させて頂きます。

背景

Appleが、2016年1月以降はIPv6環境で動作しないアプリはリジェクトすると宣言しましたので、ミクシィ社内でもその検証環境が必要になりました。

現時点ではApple側も回線から上位はv4想定のようなので、検証環境もそれに倣いLAN側はIPv6、WAN側はIPv4の構成を取りました。

構成

f:id:mixi_engineers:20160106210856p:plain

ネットワーク

  • uplinkはIPv4 only
  • クライアントはIPv6 only
  • サーバとASA間のみv4&v6 併用

機器構成

  • ASA 5505 ( NAT64 )
  • Raspberry Pi
    • DNS64 (unbound 1.5以降)
    • RA (radvd)
  • Aruba (Wi-Fi)

実は構成が確定するまでが一番苦労した部分で、当初導入予定だったDHCPv6 (isc-dhcp-server)やASAでのRA送出、BINDには色々な制限が有り、期待した機能を満たしていない事が動かしてみて初めてわかりました。この辺りの経緯は最後の【ハマったこと】に纏めています。宜しければご参照ください。

※ 以下に記述する手順はインターネット上の情報を多数参考にしています。
※ 環境の違いによって意図しない動作をする可能性も有ります、ご了承ください。
※ 間違い・改善出来る部分など多々あるかと思いますのでご指摘頂けると非常に有りがたいです。

以下configです。

ASA

まずASAから設定します。

先述の通りRAのやり取りはRaspberry piのradvdで行いますので、必要最小限のアドレス設定と、NAT64の設定です。RAの送出も抑止しています。

outsideはキャリアのDHCPサーバーからグローバルのIPv4アドレスを受け取っています。

IP設定

interface Vlan214
nameif inside02
security-level 0
ip address 10.10.214.1
ipv6 address face::10:10:214:1/64
ipv6 enable
ipv6 nd prefix face::/64 no-autoconfig
ipv6 nd suppress-ra 0 

interface Vlan2999
nameif outside01
security-level 0
ip address dhcp setroute

NAT64

IPv6をoutsideのIPv4アドレスにNAT64しています。 またRaspberry PiがIPv4でDNSを聞きに行く為、IPv4アドレスもNATします。

object network REAL_IPv6
 subnet face::/64
object network REAL_IPv4
 subnet 10.10.214.0 255.255.255.0
object network DNS64_range
 subnet cafe:ff9b::/96

nat (inside02,outside01) source dynamic REAL_IPv6 interface destination static DNS64_range any
nat (inside02,outside01) source dynamic REAL_IPv4 interface

ASAは以上です。あとは必要なセキュリティの設定と、物理インターフェースに各interface Vlanを割り当てます。

Raspberry Pi

unbound

unboundは1.5以降のバージョンからDNS64対応ですが、apt-getでは1.4系のパッケージしか無いため、ソースコードからインストールが必要です。ただし必要なパッケージが無いと多大な時間を浪費する事になります (当方はここでハマりました)。

raspberry-piの場合はlibssl-develが必須のようです。

他の手順は以下を参考にしました。

 

unbound.conf

server:
verbosity: 1
pidfile: "/var/run/unbound.pid"
use-syslog: yes
module-config: "dns64 iterator"
dns64-prefix: cafe:ff9b::/96
dns64-synthall: yes
interface: ::1
interface: face::10:10:214:235
access-control: ::0/0 allow 

forward-zone:
name: "."
forward-addr: 8.8.8.8
  • dns64-synthall: yesで、すべての問い合わせをDNS64変換するという実装になります。これをしないと、問い合わせた外部サイトがv6アドレスを持っていた場合、cafe:ff9bではなく生v6アドレスをクライアントに返してしまいます。BINDではここの実装がクリアできず、unboundに変更しました。
  • IPv6への移行という観点から言うとAAAAで接続出来るサイトにはv6通信出来た方が良いのかもしれませんが、今回はApple推奨環境と同様の動作をする環境構築が目的なので、あえてunboundを採用しています。
  • prefixをcafe:ff9b::/64にしているのは、ASAがwell-known-prefixを指定してNATできない仕様のためです。

以上でunboundは動作すると思います。

次はradvdでクライアントへIPv6アドレス、DNSサーバー、デフォルトゲートウェイを通知します。

radvd

こちらもapt-getできるバージョンが古い為、念のためソースから最新版をビルドします。以下を参考にしました。

Cross Compiling Radvd for ARM - BeyondLogic

radvd.conf

interface eth1 {
AdvSendAdvert on;
IgnoreIfMissing on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvDefaultPreference high;
AdvHomeAgentFlag on;

#フラグの設定

AdvManagedFlag off;
AdvOtherConfigFlag off;

prefix face::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};

#DNSの通知

RDNSS face::10:10:214:235
{
AdvRDNSSPreference 8;
AdvRDNSSOpen off;
AdvRDNSSLifetime 30;
};
};
  • Raspberry PiのデフォルトゲートウェイはASAに向けてください。
  • ここで設定したフラグの値でクライアントはRAを参照するのかDHCPを参照するのかが決定されます。今回の場合は全てRAを参照させたいので、M flagとO flagを共にOFFにします。
    ただし先述の通り、この設定によりWindowsに自動設定させる事はできなくなりますので、Windows側でオープンソースのアドオンを入れるか、DNSサーバーの情報は手動設定してください。
    rdnssd-win32 download | SourceForge.net
  • iPhoneやAndroidを繋がず、Windows PCやMacだけで良い場合はOフラグをonにし、isc-dhcp-serverでDNSを通知すれば自動接続出来るようになります。 

Raspberry Piは以上です。

Aruba

今回ASAからArubaまで全て同一VLANのL2構成での使用の為、IPv4と比べて特別な設定は必要ありませんでしたが、いくつか注意が有ります。

  • ipv6 enable
    この設定が入っていないと無線側がL2構成であってもIPv6のFirewall Processが働かず、正常に通信出来ません。
  • Valid user (ACL)
    ここがホワイトリストのような役割を果たしており、導入したOSバージョンによっては一定の制限が掛かっています。通信させたいセグメントを許可するように設定変更してください。
  • RA-Guard
    クライアント側から意図しないRAが発せられた時に、それをブロックします。アクセスリストに以下の記述を組み込んでください。
    ip access-list session ra-guard
        ipv6 user any icmpv6 rtr-adv deny

あとはIPv4と同じようにSS-IDを作成すれば接続できるはずです。

 

これで以上です。以下は苦労した点やハマった点などを記載します。

ハマった事

NAT絡み

  • NAT64が上手くいかない → source addressだけでなくdestの改変も必要だった。
  • well-known-prefixをDNSマッピングに指定していたがASAではNATに指定できない仕様だった

DHCPv6(isc-dhcp-server)やRA絡み

  • ASAでDHCPさせようとしたが、そもそもDHCPv6対応していない(ipv6 dhcp relayのみ対応)
    → dhcpをrelayしてRasperry PiにDHCPv6させようとする(当初raspberry piとクライアントは別セグメントだった為)
    → isc-dhcp-serverがIPv6で起動できない
    → v6起動のオプションが必要
    sudo vi /etc/init.d/isc-dhcp-server
    OPTIONS="-6"
    → 起動したものの、Androidだけ接続出来ない
    → 調べるとIPv6アドレスは取れているが、v6のDNS情報が通知出来ていない様子
    → AndroidはDHCPv6非対応の為、RAでDNSサーバー情報を渡さなければならない
    Comparison of IPv6 support in operating systems - Wikipedia, the free encyclopedia
    → RAでDNS情報を通知する為にはRFC6106をサポートした製品が必要になり、まだ多くのネットワーク製品がサポートしていない。
    インターネット用語1分解説~RA (Router Advertisement; ルータ広告)とは~ - JPNIC
    Firewall IPv6 Capabilities: Cisco, Forti, Juniper, Palo
    → 今回はアドレス情報やDNS情報のやり取りはASAではなくRaspberry Piのradvdに任せて、ASAは出口のNAT専用機とする事に変更。

DNS絡み (BINDの問題)

  • 問い合わせた結果AAAAで返ってきたアドレスはDNS64変換されず生のAAAAレコードをクライアントに返してしまう
  • ASAのNATでDNS64レンジを宛先に指定する必要があるためNG
  • unboundなら "dns64-synthall" というオプションがあるようなのでunboundに変更

無線絡み

  1. L2構成の場合ArubaのコントローラにIPv6アドレスを振らない為、IPv6を有効にする必要が無いと勘違いしていた。
  2. IPv6 enableを設定しないとFirewall(v6)も動作しない事を知らなかった。
  3. 運用中の実機のため、迂闊にIPv6 enableなどの設定変更が行えなかった。
  4. IPv6 enableを投入したものの、未だにACLに引っ掛かり通信出来ない
  5. valid userの設定変更が必要だと気づく

機器の実装の違い (最大の難関)

  • WindowsはDNS情報の通知にDHCPv6を使用しなければならないが、
  • AndroidはRAを使用しなければならない。
  • iPhoneはどちらでも構わないが、RAのやり取りが不安定で接続出来たり出来なかったりする。

以下まとめです。

  • Windows
    • RA(IP取得): OK
    • RA(DNS取得): NG (wikipediaより, 上記アドオンインストールで取得出来るようになるようです)
    • DHCPv6(DNS取得): OK
    • v6手動設定: OK
  • Android
    • RA(IP): OK
    • RA(DNS): OK
    • DHCPv6(DNS): NG
    • v6手動設定: 不可
  • iPhone (Mac OS X)
    • RA(IP): OK
    • RA(DNS): OK
    • DHCPv6(RA): OK
    • v6手動設定(DNSのみ): OK

上記よりWindows側が手動やアドオンなど頑張れる要素が多い事と、Appleの推奨環境もそういった構成を取っている為、それに倣いました。

情報の不足

海外サイト、国内サイトを含めて中々必要な情報が得られない状態でした。特に国内のサイトには一通りの情報をまとめているサイトが数える程しか無く、情報収集に苦労しました。

まとめ

Android・iOS・Windowsなどデバイス、OSによってサポート、非サポートな部分の違いが多数有る事がわかりました。本構成ではWindowsの標準機能でDNSサーバーを渡す事が出来ない点が、依然課題として残っています。(Windows側でアドオンをインストールするか、DNSのみ手動設定という手段で何とか接続させています。)

機器毎に実装が大幅に異なるIPv6が、本当にこのまま普及するのか疑問です。現状はappleが普及に向けた先導をしているように見えますが、Google, Microsoft等、業界大手が足並みを揃えなければ世界的な移行は難しいのでは無いかと思います。

謝辞

今回の構築にあたり加藤さん、吉野さんにはお忙しい中、多大なるご協力を頂きました。私一人では完成まで辿り着けなかったと思います。

本当にありがとうございました。