2017-06-13

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

AWS mixi Datadog

はじめまして。北村です。

先日行われた 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日間は値が完全に取れていないことが分かります。このため、リザーブドインスタンスの過不足状態を確認するまで時間がかかってしまいます。
時間毎の詳細な利用状況が分からない（利用状況が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

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

2015-12-20

総行数57,000の巨大CSS群をLessに書き換えた軌跡

CSS CSSプリプロセッサ mixi LESS

こんにちは！フロントエンド闇祓いの Kuniwak です。
この投稿はmixiグループ Advent Calendar 2015の20日目の記事です。

今年の9月に、スマートフォン Web ブラウザ版 mixi「mixi Touch」の巨大 CSS を Less （CSS プリプロセッサー）でビルドする環境へと移行しました。書き換えた CSS の行数は、なんと 56,725行 です。😵

ということで、今回は弊社の大規模 CSS → Less 移行事例についてお話しします。

背景

スマートフォン版 mixi は、2010年5月に始まりました。この頃のスマートフォンは、iPhone 端末であれば iPhone 3GS、Android 端末であれば Nexus One という時期です。また、スマートフォンの世界では、Webkit ベースのブラウザーが席巻していた時代ということになります。

そのため、当時の CSS は Webkit ベースのブラウザーのみを考慮した書き方が多く見られました。たとえば、次のような -webkit- プレフィックスを使った書き方です：

/* 非標準の CSS プロパティ fuga を使う場合の書き方 */
.hoge {
  -webkit-fuga: moge;
  fuga: hoge;
}

この -webkit- プレフィックスは非標準（または実験段階）の機能などを先行して利用するためのものです。ただし、実験段階の機能ということだけあって、標準化される過程で CSS プロパティの名前が変わったり、別仕様に取り込まれてしまったりするリスクがあります。

そのため、-webkit- のようなベンダープレフィックスを使うためには、変更されたときの影響を小さくしたり、書き換えを楽にするような工夫が必要とされます。

しかし、当時の弊社の CSS では、次のような悪い書き方が散見されました:

/* 潜在的な問題を抱えたコード */
.something {
  -webkit-background-size: 8px 8px;
}

このコードは、当時のモバイルブラウザーであれば意図通り表示されることでしょう。しかし、この書き方には3つの潜在的な問題があります。

非 Webkit ベースのブラウザーを考慮していない
-webkit- つきのプロパティが標準になったときの書き換えが大変
-webkit- つきのプロパティが非標準になったときの書き換えが大変

当時から問題は認識されていたものの、問題への対処は見送られていました。
そして、5年経った今になって、この3つの問題が顕在化したのです。

この問題の解決のために、HTML コーダー（マークアップエンジニア）2名 + 技術支援1名 + テスター1名の体制で対応作業を始めました。

問題1: 非 Webkit ベースのブラウザーを考慮していない

-webkit- プレフィックスをつけたプロパティは、非 Webkit ベースのモバイルブラウザー（Android 版 Firefox や Windows Phone の IE など）では解釈されません。しかし、これらのシェアが小さいためか、-webkit- プレフィックスのみの CSS が世に溢れています。

そこで動き出したのが Mozilla です。 Mozilla には WebCompat Team なる部署があり、-webkit- のみの CSS を使っている Web サイトへの啓蒙活動をしているそうです（Mozilla の方による記事 WebCompat）。 mixi に対しても Mozilla からのコンタクトがありましたが、あまりの -webkit- プレフィックスの多さから見送られた、苦い記憶があります。😢

また、啓蒙活動とは別に、Firefox のコード側にも動きがありました。それは、特定のドメインの CSS では、-webkit- プレフィックスを外して解釈するというものです。つまり、ドメインによって CSS の解釈が変わることになります。この動きについては Mozilla 側の対応チケットを見ると何がおこなわれたのかわかります。

実は、この Mozilla 側での動きが、Less 化の強い動機になりました。これは、弊社のステージング用の環境では専用のドメインが使われていることに起因します。そのため、本番環境とステージング環境での CSS 解釈に差が出てしまうのです。これではステージング環境の意味がありません。

つまり、非 Webkit なブラウザーに注意を払わなかった結果、ブラウザーベンダーがお怒りになり大変なことになったのでした。

問題2: `-webkit-` つきのプロパティが標準になったときの書き換えが大変

ベンダープレフィックスつきのプロパティは、そのまま標準化されることがあります。この場合、-webkit- をつけたままのものは廃止予定（deprecated）になります。そのため、「最後にプレフィックスなしのプロパティを付け加える」ことで、標準化されたものを優先的に利用する書き方が推奨されています。

.something {
  -webkit-background-size: 8px 8px;
  background-size: 8px 8px;
}

しかし、弊社の CSS には、プレフィックスなしのプロパティを併記しないものが多く見られました。このような CSS がおよそ 57,000 行もあるのですから、推奨されている書き方に直すのも大変です。

つまり、推奨される書き方に従わないままコードが育っていった結果、推奨の状態に戻すことが困難になっていました。

問題3: `-webkit-` つきのプロパティが非標準になったときの書き換えが大変

ベンダープレフィックスつきの機能が標準化される過程で、CSS プロパティの指定方法が変わったり、機能自体が削除されることがあります。

たとえば、mixi の CSS には、相当前に非標準となった box 仕様のプロパティが使われていました。この件は Mozilla でも問題になっていたらしく、「mixi.jp Mobile version is using the old-old CSS webkit flexbox syntax」というチケットがつくられており、個人的にはとても恥ずかしい気持ちでいっぱいでした。

このような機能は廃止予定になることが多く、何かの拍子に取り除かれてしまっても文句は言えません。そのため、廃止予定になった時点で書き換える必要があります。しかし、既に行数が膨らんでしまった CSS を仕様変更の都度に書き直すのは大変です。

まとめると、非標準な機能を多用すると、非標準の機能が消されることに怯える日々を過ごすことになることがあります。

問題への対処の軌跡

救世主 Autoprefixer

これらの問題に対処するために、Autoprefixer というツールを使うことにしました。 Autoprefixer は、指定した環境に合ったベンダープレフィックスを自動的につけてくれるツールです。

/* Autoprefixer 適用前 */
.example {
   background-image: linear-gradient(#e87451, #c42f02);
}

/* Autoprefixer 適用後 */
.example {
   background-image: -webkit-gradient(linear, left top, left bottom, from(#e87451), to(#c42f02));
   background-image: -webkit-linear-gradient(#e87451, #c42f02);
   background-image: -moz-linear-gradient(#e87451, #c42f02);
   background-image: linear-gradient(#e87451, #c42f02);
}

この Autoprefixer を使うと、問題の1と2を解消できます。問題3についても、Autoprefixer が可能な限り標準の書き方へと変換してくれます。

ただし、Autoprefixer は既にベンダープレフィックスがついているプロパティに対しては何もしません。そのため、前作業として CSS のベンダープレフィックスを外すように書き換える作業が必要になります。

CSS:fixme で Autporefixer の下ごしらえ

前述の通り、Autoprefixer の下ごしらえとして、既存の CSS からベンダープレフィックスを取り除く必要があります。

このために、CSS:fixme というツールを使いました。このツールは Mozilla の方が開発しているオープンソースのツールで、ベンダープレフィックスつきの古い記法を、Autoprefixer にかけられるような記法へと変換してくれます。

ただし、巨大なファイルで作業するにはコマンドラインによる変換の方が便利だったため、魔改造をおこないました（魔改造後のコードは MPL ライセンスにしたがって公開しています）。

また、CSS:fixme で変換されないものもありました。変換されない理由は、未標準だからか、変換対象から漏れていたかのどちらかです。この部分は、マークアップエンジニアの方と細かく結果を確認しながら作業を進めました。

このベンダープレフィックスを外す作業が、全体のおおよそ半分を占めています。

Less 導入

さて、救世主 Autoprefixer を使うためには、CSS をビルドする必要が生じます。そして、どうせビルドするならということで、CSS の表現力を補う CSS プリプロセッサー Less を導入しました。つまり、Less 移行は、Autoprefixer 導入のついでという側面が強かったのです。😜

さて、CSS から Less へ移行すると変数が使えるようになります。これによって、保守性を格段に向上させられます。

たとえば、カラーレギュレーションの色を変数にしておくだけでも、管理しやすいことは明らかです:

//- `@basicTextColor`: 基本のテキストカラー
@basicTextColor: #333;

//- `@subTextColor`: 基本よりすこし弱め
@subTextColor: #666;

// ...

カラーレギュレーション以外にも、アイコンフォントのコードポイントを変数によって集中管理しています。また、私個人としては z-index についても変数で管理することを目指しています。

さて、Less の他にも Sass という有名な CSS プリプロセッサーがあります。ここで Sass ではなく Less を採用した決め手は、それぞれの提供されているエコシステムにあります。 Sass は Ruby のエコシステムで提供されていますが、Less は Node.js のエコシステムで提供されています。そして、Node.js の方が、Perl と同居させるのに都合がよかったのです。

`-webkit-box` との格闘

これで平和が訪れるかと思いきや、-webkit-box という厄介な問題が立ちはだかりました。

この -webkit-box は、横並び/縦並びの要素の表示制御に関する機能です。これと同等の機能を実現するためには多大な労力が必要なため、非標準だった当時から重宝されていました。

ただし、この仕様は box（2009年）→ flexbox（2011年）→ flex（現在の最終草案の仕様）と 3 度大きく変更されました（仕様の変遷については flexboxの旧仕様、改定仕様、現行仕様の一覧 « LINE Engineers' Blog という素晴らしいまとめ記事があります）。そして、-webkit-box はこのうち最も古い仕様で、Autoprefixer が適用できる状態にするには大幅な書き換えが必要です。

たとえば、CSS:fixme は可能な限り -webkit-box を最新の仕様である flex に書き換えてくれます。しかし、display: -webkit-box があたっている要素の子要素の width に問題が生じます。

-webkit-box 仕様では、width が指定されていれば flex-basis 指定と同等の効果がありました。しかし、flex を使う時には明示的に flex-basis を記述しなければなりません。

すると、CSS:fixme が width プロパティに遭遇したとき、これが flex-basis に相当するのか、それとも通常の width なのかを区別する必要があります。このような書き換えは、セレクタの対象の親子関係を考慮できなければ実現できません。

/* ... */

.moge {
  /* 
   * この width の意味は、親要素に display: -webkit-box が
   * あたっているかどうかで変わってしまう
   */
  width: 10px;
}

/* ... */

つまり、BEM のような命名規則で CSS から親子関係を推測できない限り、機械的な検証は困難です。この問題は、2人がかりでのコードレビューと、凄腕テスターによるステージング環境での動作確認で洗い出しました。

このような QC（品質管理）作業に、残り半分の作業時間が費やされています。この甲斐あって、57,000 行に渡る書き換えにもかかわらず、不具合報告はきていません。

Less 化における QC への技術的支援

これまでの作業で、Autoprefixer による問題解決が実現できました。しかし、このままでは、まだ Less の機能を活用できていません。宝の持ち腐れの状態になっています。

そこで、次のフェーズとして、Less の機能を利用するようにリファクタするフェーズがはじまりました。

このフェーズでは、生成される CSS が変わらないことを期待できます。すると、CSS の AST（抽象構文木）による比較が可能になります。AST による比較では、CSS 内の改行位置や空白の取り方に左右されないため、よりブラウザーの CSS 解釈に近しい結果がえられます。この AST がリファクタ前後で変化していなければ、表示に差異がでないことが期待できます。

ただし、Less のような CSS プリプロセッサーを使えば、AST に差は出てしまうものです。この AST の差で重要なのは、セレクタ・プロパティの過不足と、ルールの記述順序の2点です。

ここで重要なのは、この2点の深刻度に違いがあることです。たとえば、セレクタ・プロパティの過不足は、記述漏れの可能性を強く示唆します。これに対して、ルールの記述順序の差は、スタイルの上書きの可能性を示唆するものの、影響はごく軽微です。この2つを混同してしまうと、深刻度の高い警告が深刻度の低い警告に埋もれてしまうといった問題が生じてしまいます。ようするに、この2つは分解して観察することが重要なのです。

そして、既存の CSS の AST 比較ツールには、プロパティの過不足とルールの記述順序を分解して比較できるツールが存在しませんでした。そこで、css-semdiff というツールを開発しました。

たとえば、css-semdiff を使うと、次のようにプロパティの過不足が発見できます。このプロパティの過不足は、ルールの記述順序に影響されません。

$ css-astdiff a.css b.css --verbose
extra:
        #header ul {
          display: -webkit-box;
          display: -webkit-flex;
          display: -moz-box;
          display: flex;
        }

missing:
        #header ul {
          display: -webkit-box;
          display: -webkit-flex;
          display: flex;
        }
23 extra rules and 23 missing rules between a.css and b.css

また、ルールの記述順序の差異のみを発見することもできます:

$ css-orderdiff a.css b.css --verbose
order changed: #footDisplay
        become to be higher than:
                .error #mainDisplay,
                .webView01 #mainDisplay

order changed: .error #mainDisplay
        become to be lower than:
                #footDisplay

このフェーズでは css-semdiff を活用した結果、複数の不具合を未然に防止できました。この css-semdiff は、MIT ライセンスで公開しています。ぜひ、QC 作業にお役立てください！

後日談

この話は、私が新卒だったころに諦めた Firefox 対応を、1年越しに達成した話でもあります。それだけに、個人的にも思い入れの深い仕事です。

ちなみに、この作業を終えたところ、Mozilla の方からお礼のお返事をいただきました。

This is fixed. \o/
Thanks to Mixi team and their hard work.

With a lot of love from Mozilla.

この仕事に携われてよかったと思えた瞬間です。😝

まとめ

弊社のスマートフォンページでは次の3つの問題が生じていました。

非 Webkit ベースのブラウザーを考慮していない
-webkit- つきのプロパティが標準になったときの書き換えが大変
-webkit- つきのプロパティが非標準になったときの書き換えが大変

そして、これらの問題を次のようなツール/活動で解決したという話でした。

Autoprefixer
CSS:fixme
コードレビューなどの QC 活動
css-semdiff

次は esugita さんの「Find Job!っていう求人メディアに関わってるので、採用とかとか。」です。

宣伝

ミクシィでは、技術を駆使して負債に立ち向かう闇祓いエンジニアをいつでも歓迎します！闇祓いスキルをつけておくと、光環境/闇環境を選ばない技術力がつくことでしょう。

ともに闇祓い、してみませんか？

2014-11-12

VimConf 2014 と Vim と mixi

vim seminar mixi

こんにちは。エンジニア兼 Vimmer、Kuniwak です。11月08日（土）、Vim の国際的な会議「VimConf 2014」が弊社でおこなわれました。

VimConf では、Vim の機能の詳細な解説や、自作プラグインの紹介、Vim の未来など、多くの Vim に関するディープな知識が発表されています。また、登壇者陣も非常に豪華で、Vim のコントリビュータから、Github で 1,500 もの☆がつく有名プラグインの作者など、Vim をとりまくさまざまな開発者が登壇しています。

発表タイトル一覧は、Timetable - VimConf 2014 をご覧ください。

なお、ミクシィも Vim に支えられている一企業として、Vim との関係についてお話ししました。

それぞれの発表の様子

2014-10-29

mixi SNSを攻略しよう! Scrap Challenge 2014年度シーズンのご案内

intern mixi recruiting security seminar mixi_scrap

Aphex Twinの13年ぶりの新譜 'Syro'、捨て曲なしで素晴らしいですね。もりもとです。

株式会社ミクシィで毎年開催している、学生向けのWebセキュリティ実体験イベント 'Scrap Challenge' が、2011年に始めてからかれこれ4年目になりました。
もちろん今年度もやってますよ! ということで、これまでの道のりと、改めての内容のご紹介です。

f:id:mixi_engineers:20141028142113j:plain

自社サービスを攻撃させるイベントを思いつく

どこの会社でも、優れた能力をお持ちの方と知り合いたいと思うのは同じです。
また、どうせなら面白いことをやろうと考えるのも大事なことだと思います。ある課題に対する解決策がいろいろあるとき、「可能性」「重要性」「簡単さ」といった軸で切り分けて、それぞれの判断をもとに総合的にどうするか決めるというやり方*1がありますが、いずれも甲乙つけがたいぞ、といったケースでは、「やって面白いかどうか」も加味すべき評価軸だと考えます。課題はひとが成すものですし、ひとに取って面白さは大事なこと。課題自体がひとの交わりであれば、なおさらです。

ミクシィの仲間を採用していくうえで、優れたよい人たちとご縁を作っていくにはどうしたらいいか。エンジニア領域において、技術力や課題解決能力に実技面でも優れたみなさんとどうやって知り合っていくか。
それにはプログラム・コンテストなどいろんな方法がありますが、他にはないユニークなものをやってみたい。そこから2011年の夏頃に思いついたのが、「わざと脆弱性を作り込んだSNS mixiのクローンをみんなで攻撃してもらう」という、Scrap Challengeという技術イベントです。
一種のCTF風味もあると思います。企画立案中は「風雲! たけし城」と呼んでいました。

f:id:mixi_engineers:20141028141953j:plain

思いついたはよいのですが、社名をそのまま背負っている、ユーザのみなさんのプライバシーもお預かりしているサービスの、たとえクローンとはいえ、サイトを参加者に疑似攻撃してもらう技術イベントというものが社内で認められるか。ひょっとしたら微妙かな、怒るひとがいるかもなぁ…… とも思いつつ提案をまわしてみましたが、拍子抜けするほどに「それ、面白いね!」という反応が得られ、じゃあ各種機能のどのへんにどう穴をあけていこうか、という検討に進むことができました。このへんは、課題を面白い方法で解決していこうじゃないかという社風のよいところ、風通しのすっきりしたところだと思います。

どういう穴を開けていこうか、たとえばport 22にsshdを開けておいて、でもそれはhoneypotだよ、あるいはパケットレベルでいじってもらい…… と企画は膨らみましたが、ある程度いろんなスキルの方にWebセキュリティの実技を体験していただきたいという思いもあったので、当初はいわゆるXSS的な課題にしぼっています。実技を通した競い合いでもありますが、それ以上に、普段はできない体験をしていただき、学んでもいただければうれしいと感じているからです。参加者のみなさんに「面白かった」という体験を持ち帰っていただくのが一番大事なことです。

Scrap Challengeに出てくる課題たち

イベントは、弊社で勉強会やイベントをよく開催している「コラボルーム」にお昼まえに集合いただき、まずはWebセキュリティ概論からご説明します。
一般的なお話だけでなく、mixiというSNSが長年体験してきた、いろんなissueも含んで、実例をあげて説明していきます。
そのあとはみなさんの環境設定も兼ねたチュートリアル。
これから攻略する「偽mixi」にログインしていただき、弊社が設けた「やられ役」のmixiユーザたちとマイミクになっていただいたりします。
「やられ役」は、当日アテンドするミクシィ社員が務めます。挑戦者から送られてきたmixiメッセージを、全部言われたとおりに開いてクリックするなど…… この係の呼び名は「鴨ネギ」です。

f:id:mixi_engineers:20141028141955j:plain

その後、簡単な実例を、チューターと共に解いてみて、この手のアタックがはじめての方への手ほどきや、ウォーミングアップも兼ねます。
アイスブレイクを兼ねた昼食もはさんで、そのあとがいよいよ実技です。

f:id:mixi_engineers:20141028142000j:plain

実技の時間は2時間半設けています。攻略すべき課題がみなさんに示され、偽mixiに挑んでいただきます。時間を追って、だんだんヒントが出てきたりしますが、そのかわり課題攻略成功時に得られるポイントは減っていったりします。ゲームバランスってやつですね。

f:id:mixi_engineers:20141028142003j:plain

f:id:mixi_engineers:20141028142008j:plain

具体的な内容の説明は…… ここでは控えさせていただきます。ご興味お持ちのみなさんは、ぜひエントリしてお試しください!

かれこれ運営3年め

Scrap Challengeを最初に開催したのは2011年の冬です。

&amp;amp;amp;amp;amp;lt;a href="http://alpha.mixi.co.jp/entry/2012/10794/" data-mce-href="http://alpha.mixi.co.jp/entry/2012/10794/"&amp;amp;amp;amp;amp;gt;mixi Scrap Challenge - 学生向けイベント - mixi Engineers' Blog&amp;amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;amp;gt;

&amp;amp;amp;amp;lt;a href="http://togetter.com/li/223188" data-mce-href="http://togetter.com/li/223188"&amp;amp;amp;amp;gt;株式会社ミクシィ学生向けエンジニアイベント "Scrap challenge 2011"の参加者tweetまとめ&amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;gt;
当時は社内の開発用サーバの一部を専用に割り当てて偽mixiを稼働させましたが、競技開始直後に思いのほか負荷が高くなり、その場で速攻で台数を増やしたりなど…… 想定と違うところで攻略されてしまったりしました。

それから、いったんAWSにプラットフォームを移したり、社内で開発運用している仮想サーバ運用プラットフォーム 'Gizmo' で動かしてみたり (くわしくは「OpenStackとLXCを導入した話 - mixi Engineers' Blog 」をご覧ください)、運用側もさまざまなトライを繰り返しています。

出題面でも、むやみに難しくせず、とはいえ攻略の楽しみも確保したいと、言うなればゲームバランスも大事なところです。
先日まで、全問攻略完了チームはいませんでした。あと20秒あれば全問正解だったのに…… というチームがこれまでのベストだったのですが、ついに2014/8/23の回で、全問クリアのチームが出てしまいました。微妙にくやしい……(笑)

とはいえ、通算8回も開催してきた結果、いままで157名もの学生のみなさんに出場いただきました。その中には、Scrap Challengeを通してご縁ができて、いまは同じくミクシィで活躍されている若手エンジニアも10名近くいます。加えて、インターンとして実務体験のご縁ができたみなさんも。
気がつくと、Scrap Challengeで知り合った学生さんだったみなさんが、いまやミクシィの若手エンジニアとして、Scrap Challengeの司会や解説、あるいは鴨ネギをやってくれたりしています。企画の言い出しっぺとしては嬉しいかぎりです。

Scrap ChallengeはSNS mixiを題材としていますが、ご縁となって入社されたみなさんは、モンスターストライクであったり、あるいはDeployGateであったり、もちろんSNS mixi、あるいは新規事業と、Webアプリケーションやネイティブアプリ、ミドルウェアといったレイヤにかかわらず、優れたエンジニアとして活躍していただいています。

何かしらWebやネットワークに関わる立場であれば、Webセキュリティに関する実務的知識は素養として大事ですし、そういった知識をイジワルな課題に対してあれこれ行使する地頭と突破力は、どんなエンジニアリング領域にも通底する能力だと思います。

f:id:mixi_engineers:20141028142011j:plain

このように、他では中々できない技術体験を一緒に行うと、学生さん側も、社員エンジニア側も、体験共有を通して仲良くなれます。

技術解説の中にはオフレコなトピックもありますし、その後の懇親会でも、フードや飲み物と一緒に、楽しく濃ゆい語らい(S式な話とか、マニアックなコンパイラの話とか……)や、ミクシィのエンジニアのワークスタイルや考え方など、エンジニア志望のみなさんには楽しい時間だと思います。

f:id:mixi_engineers:20141028142016j:plain

ともあれ、Scrap Challengeのねらいは「おもしろかった! と思ってもらうこと」です。
せっかく足を運んでいただくリアルイベントなのですから、他ではできないユニークな体験知見を過ごしていただくこと。これが大事です。
よき採用につなげたい思いももちろんありますが、エントリいただくみなさんが新卒採用年度にマッチするかどうかは、それほどこだわっていません。

f:id:mixi_engineers:20141028142018j:plain

今年度(2014)は、すでに夏休み中の2014.8.23に一回開催し、次の開催は2014.11.16(日)です。2014.11.5までエントリ募集中です。募集数によっては、2015.1.17にも続けて開催の予定はあります。11月がゼミなどで忙しい方は、ぜひ1月を楽しみにしていてください。

当日の様子は、みなさんにどんどんtweetしていただくのも歓迎しています。ネタバレはダメですが…… 我々もその模様を毎回togetterしたりしています。#mixi_scrapで検索していただければ、いままでの様子がわかると思います。

ほほう、と思った方は、ぜひ見てみてください。

そして、いつか将来のScrap Challengeを、ともにネタ出ししたり開催したり、新たな挑戦者の学生さんと語らったりする側に、一緒に立てれば嬉しいです。

f:id:mixi_engineers:20141028142020j:plain

*1:Potential + Importance + Ease = Scoreで考える、PIESフレームワークってやつですね

2014-03-31

OpenStackとLXCを導入した話

cgroups fedora LXC mixi openstack

こんにちは、運用部アプリ運用グループの清水です。Golang鋭意勉強中です。

今回は、SNS「mixi」に限った話ではなく、ミクシィ社全体として利用している仮想環境について紹介したいと思います。パブリッククラウドも一部のサービスで利用していますが、今回は、自社で運用している仮想環境にフォーカスして書いてみようと思います。

今まで利用してきた仮想環境

今まで利用してきた仮想環境というと、手作業で構築したKVM（Kernel-based Virtual Machine）環境が中心でした。手作業といってもある程度手軽に構築できるように、シェルスクリプトとCobblerでVMを構築できるようになっています。構築の流れは以下のとおりです。

CobblerにVMのIPやホスト名などをスクリプトで登録する。
KVMのホスト上でスクリプトを実行（koanコマンドでCobblerと連携してVMをセットアップ）

VMの数が少ないうちは、この方法でも問題は大してありませんが、VMが増えてきたり用途が多様化してくると、VMの管理や物理障害時の対応が非常に面倒になるという課題を抱えてきました。

2014-02-13

「Photo Hack Day Japan」参加者受付開始のお知らせ

Android iOS mixi

先日告知しました、Aviaryと共同で開催する「Photo Hack Day Japan」の参加応募を受付開始したのでこちらでも告知させていただきます。

多数のスポンサー企業様から協賛頂いたおかげで、今回のイベントは賞金総額60万円+α!しかもプレパーティーから開催期間中の食事まで、全て無償提供となっていますので、是非こちらから奮ってご参加ください!

概要

APIスポンサーから提供された最新の写真に関するAPIを使い、iPhone/Androidアプリを開発

(詳細につきましては公式サイトをご覧ください。)

賞金

最優秀賞：30万円

2等賞：20万円

3等賞：10万円

スポンサー賞(※)：スポンサー各社からの賞品

※スポンサー賞はAPIスポンサーがそれぞれに賞を設定しており、各APIごとに、そのAPIを利用したアプリの中で最も優れていると審査されたチーム/個人にそのAPIを提供するスポンサー企業から賞品が贈られます

参加資格

エンジニア：ウェブ開発、iPhone、Androidアプリ開発などのいずれかの経験
UI/UXデザイナー：Illustrator・Photoshopの基本スキル

参加方法

こちらのpeatixのURLで受付しております
参加受付URL：http://photohackdayjapan.peatix.com/
定員：150名(先着順)
※申し込みは個人でもチームでも歓迎です。
※個人で申し込んで、プレパーティーでチームを組んで頂いても大丈夫です。

日程

2月21日（金）

19時〜22時 / Pre-Party

shutterstock様のご厚意により、イベント前夜祭を開催します。参加受付方法などはハッカソン参加者の方に別途ご連絡さしあげます。
もちろん参加無料ですので、ハッカソンに参加される方は是非ご参加ください。

2月22日（土）

09:00 / 開場〜 22:00 / 1日目終了

開場は9時で10時にはAPIデモなどの説明が始まりますので、10時にはご来場をお願いします。

23日（日）

09:00 / 開場〜12:00/ 成果物の提出〜15:30 / 結果発表

12:00に成果物の提出がありますので、実質12:00までが開発に使える時間だと思ってください。

※22日は朝昼晩の3食、23日は朝昼の2食が無償提供になります!

会場

株式会社ミクシィ - 東京都渋谷区東1-2-20　渋谷ファーストタワー
(渋谷駅から歩いて10分弱くらいです)

協賛

多数の企業からスポンサー参加頂くことになりました。2014年2月7日時点での参加企業は以下の通りです(敬称略)

お問い合わせ先

本イベントに関する詳細は下記メールアドレスよりお問い合わせください。

株式会社ミクシィ
〒150-0011
東京都渋谷区東1-2-20
住友不動産渋谷ファーストタワー7F

phd5@mixi.co.jp

2013-12-18

「Photo Hack Day 5」スポンサー募集開始のお知らせ

Android iOS mixi

すっかりご無沙汰しております、スマートフォンアプリエンジニアの七尾です。
この度ビジネスパートナーのAviaryと共同でハッカソンを開催する事になりました。
一般応募に先立ちまして、この場を借りてスポンサー募集のお知らせをさせていただきます。
参加者の募集につきましては決まり次第、公開いたします。

Photo Hack Dayを日本で初開催します！

2014年2月21日（金）～23日（日）に、株式会社ミクシィとAviary社でPhoto Hack Day 5を共同開催いたします！

Photo Hack Day とは、写真編集に関するAPIを使って短期間で行うハッカソンのことです。Aviary社はこれまで4回Photo Hack Dayを開催し、1,500人以上の開発者、デザイナーが参加し250個以上のサービスを作ってきました。

2013年4月にニューヨークでFacebook社とAviary社で共同開催したPhoto Hack Day 4では、300人以上のエンジニア、デザイナーがチームを組み、Dropbox、FUJIFILM、tumblrなどのAPIを利用して63個のサービスを作りました。その中でも優秀なサービスはThe Next WebやTechCrunchなどで取り上げられました。

今回で5回目の開催となる本イベントでは、エンジニア、UI/UXデザイナーに参加していただき、写真編集加工に関するAPIを中心にさまざまなAPIを利用して、写真加工に限らず、SNS、ゲーム、e-コマースなど多岐にわたるサービスの開発を行います。

開催概要

主催：株式会社ミクシィ、Aviary, Inc. 日程：2014年2月21日（金）～23日（日）場所：株式会社ミクシィ人数：150名参加対象者：エンジニア、UI/UXデザイナーイベント内容：

基調講演
APIデモ、ワークショップ
メインイベント
プレゼンテーション
結果発表

ご支援のお願い

Photo Hack Day 5開催にあたり、スポンサーになっていただける企業・個人の方々を募集しております。つきましては、以下の内容をご高覧頂き、スポンサーとしてPhoto Hack Day 5への協賛をご検討頂けますよう、よろしくお願いいたします。
スポンサー特典は以下のとおりです。スポンサー額、特典などの詳細はお問い合わせ先メールアドレスまでご連絡ください。