技術本部 秋葉原ラボの高野です。2016/06/09に開催された人工知能学会全国大会にて、河津裕貴氏、鳥海不二夫准教授（共に東京大学大学院工学系研究科）との共同研究結果が発表されましたので、それについて報告いたします。

　　弊社で運営しているサービス（AbemaTV、AWA、アメーバピグ、アメーバブログ、ソーシャルゲーム）には多様な使用スタイルが存在し、そのすべてを把握し評価することは困難です。

　　本研究では、その多様な既知・未知の使用スタイルを発見し評価することを目的としたデータマイニング手法を開発しています。本発表ではソーシャルゲームに焦点を当て、そのプレイスタイルの発見を試みました。第一に隠れマルコフモデルを用いてユーザの抽象的な状態を抽出し、それの状態遷移ネットワークを構築、第二に、その状態遷移ネットワークのコミュニティをプレイスタイルと考えて分析し、その結果と考察を報告しました。

発表原稿

河津裕貴, 鳥海不二夫, 高野雅典, 和田計也, 福田一郎, "潜在状態ネットワークに基づくソーシャルゲームユーザの行動抽出", 第30回人工知能学会全国大会, 4D4-2, 2016.

関連発表

河津裕貴, 鳥海不二夫, 高野雅典, 和田計也, 福田一郎, "隠れマルコフモデルを用いたソーシャルゲームユーザの分類", 第35回ゲーム情報学研究会, 2016.

参考

秋葉原ラボの過去の発表一覧

どうもこんにちは。技術本部でサーバサイドエンジニアをしている池田 (@yukung) です。約4年振りの投稿になります。こち亀の日暮さんばりの登場頻度でスミマセン。

実は私、今ラスベガスのホテルにてこのエントリを書いています。なぜそんなところに居るのかというと、ラスベガスで開催されている SpringOne Platform (https://springoneplatform.io/) というイベントに参加しているからです。

Image may be NSFW.
Clik here to view.

SpringOne とは

ご存知の方もいらっしゃるとは思いますが一応軽く説明しますと、 Java のデファクトスタンダードなフレームワークである Spring とそのエコシステムをフィーチャーしたイベントで、去年も SpringOne 2GX として開催されました。今年から SpringOne Platform としてリブランドされ、Spring だけでなく、 OSS の PaaS である Cloud Foundry や、マイクロサービス、DevOps、データ分析、マシンラーニングなど、扱う内容が多岐に渡っています。

Image may be NSFW.
Clik here to view.

弊社では昨今、 golang によるマイクロサービスアーキテクチャが花盛りですが、 Java も同じく Spring Boot や Spring Cloud のエコシステムを中心としてマイクロサービスアーキテクチャや Cloud Native への流れがやってきています。そんな中で、海外での技術動向などを肌で感じたいと思い、ここラスベガスまでやってきました。

さて、初日の今日は、開幕前日の様子と、前夜祭のような IGNITE HAPPY HOUR と IGNITE TALKS の様子をレポートしたいと思います。

開幕前日の様子

会場は、ラスベガスの Aria Resort & Casino で行われています。私の宿泊するホテルもここ Aria なので、会場へのアクセスが非常に楽チンで最高です。

Image may be NSFW.
Clik here to view.

宿泊している部屋から

Image may be NSFW.
Clik here to view.

夜景

Image may be NSFW.
Clik here to view.

会場近くに来てみると、展示が行われており、開幕直前の熱気が伝わってくるようです。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

今回は前日でも参加登録が行えたので、早速 register を行います。 register は事前に登録したメールアドレスを会場に用意されているタブレット端末に入力すると、以下のように登録証のイメージが表示されました。

Image may be NSFW.
Clik here to view.

これで Print Away のボタンをタップして登録証の受取エリアに行くと、係の方がその場で登録証を作成してくれました。作成された私の登録証です。ついでにTシャツの交換券と記念ボトルも貰えましたｗ

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

IGNITE HAPPY HOURS

前夜祭ともいうべき、 IGNITE HAPPY HOURS では、入るやいなやお酒や食べ物がバンバン振る舞われ、一瞬でエンジニアの社交場と化しました。私たちも他に日本から来ているエンジニアの方々と情報交換。昨年の SpringOne にも参加された方も居て、去年よりも規模が大きくなっていることなども聞くことができました。

Image may be NSFW.
Clik here to view.

また、アジア系だからか韓国と中国のエンジニアの方からも声をかけられ、滞りつつも英語でなんとかコミュニケーションを図ってみました。中国のエンジニアとは、どんな企業で働いているのか、企業規模や注目しているトピックなどなどをお互いに情報交換をしつつ、彼が注目しているトピックは Spring Cloud と Cloud Native だとのこと。

やはり Spring Cloud を前提とした Cloud Native アーキテクチャは注目度が高いようです。

また、ここで自社のサービスの説明を試みたのですが、上手く説明できず、悔しい思いもしました。私のボキャブラリーの乏しさが根本的な原因ではありますが、日本では一言で通じるキーワードでも、海外では全く通じないことを痛感したりして、グローバルな注目を集めるサービスを持つことの重要さと難しさを改めて知ることになりました。こういう悔しい経験も、海外カンファレンスの醍醐味ですね。

IGNITE TALKS

飲み食いもそこそこに、1時間もすると IGNITE TALKS が始まり、皆が一斉にステージの方へ集まります。IGNITE TALKS (http://www.ignitetalks.io/) とは、日本でも定着している LT と同じように短いプレゼンテーションですが、形式が少し異なり、20枚のスライドを自動的に15秒でスライドさせ、その5分間でプレゼンターが喋るというスタイルのプレゼンテーションになります。個人的には日本ではこのスタイルのプレゼンテーションはまだあまり見たことがない気がしますがどうでしょうか。

トークタイトルの一覧はこちらです。(https://2016.event.springoneplatform.io/schedule/sessions/ignite_springone_platform.html)

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ここでは既に酒も入っていることもあり、終始和やかかつウケ狙いのトークが展開されていました。みながこの場を楽しんでいる、そういう雰囲気が最高でした。

そんな中、日本代表とも言うべき楽天の椎葉さん (@bufferings) が堂々たるプレゼンを全編英語で披露されていました。タイトルは DDD+CQRS on Spring Cloud で、導入からまとめまで話の流れも素晴らしく、スライドも手作り感溢れる手書きスライドを披露し、プレゼン終了後は会場から拍手喝采でした。かっこ良すぎる！

Image may be NSFW.
Clik here to view.

所感

初日の感想としては、とにもかくにもカンファレンスの規模に圧倒されたことと、月並みですがただただ英語力への渇望を掻き立てられました。このエンジニアブログでも、過去記事に海外カンファレンス参加のレポートがいくつかありますが、みな口を揃えて書いているのが英語力の不足です。私も例に漏れず同じ思いをすることになり、初日からモチベーションを揺さぶられる一日でした。明日からはいよいよ開幕です。同行している弊社エンジニアの山田から濃密なレポートをお届けしてくれると思います！お楽しみに！

おまけ

お約束のカジノですが、同行している日本人エンジニアの何人かは何百ドル勝った、という景気のいい話が聞こえてきたりしましたが、私はドル札を溶かしまくるだけという残念な結果だったので、こんなところでお茶を濁したいと思います。

こんにちは。Ameba 統括本部のポイントプラットフォーム事業室でサーバーサイドエンジニアをやっている山田です。
普段はスプラトゥーンというゲームで狙撃手を務めつつ、ドットマネーという Ameba のポイントサービスの保守・開発をしています。

さて、今日も昨日に引き続き、 SpringOne Platform のレポートになります。
このイベントについて詳細を知りたい方は、昨日の記事をご覧ください。

TimeLine

今日のスケジュールはこんな感じ。

Image may be NSFW.
Clik here to view.

朝から晩までみっちり予定が入ってます。

Main Stage

9:00am から Main Stage が始まりました。

Image may be NSFW.
Clik here to view.

広くて薄暗い会場に重低音の効いた心地よい電子音が響き、否が応にも気持ちが高揚しました。

Pivotal の錚々たる方々が、手の込んだ Keynote で会場を湧かせます。技術的な話というよりは開発プロセスやチームビルドの話がメインで、 Cloud Foundry や Spring Boot、 OSS によりもたらされる DevOps や Microservice、 Continuous delivery の恩恵の話が多かったです。

最後は Stephane Nicoll と Josh Long の2人が、 Spring Framework 4.3、 Spring Boot 1.4 の新機能を漫才形式(？)で紹介して笑いをとっていました。

Test ユーティリティが充実したり、 Actuator で Gitコミットが見れたり、 Cache を同期化できたりと、様々な新機能が紹介されましたが、一番盛り上がったのは起動時のログに好きなロゴを表示できる機能だったと思いますｗ

Image may be NSFW.
Clik here to view.

Main Stage は間違いなくこのカンファレンスの一番の見所で、スケールの大きさ、クオリティの高さに終始圧倒されました。

Modern Java Component Design with Spring Framework 4.3

Main Stage 以降は、複数のルームでセッションがあるので、自分で何に参加するかを選択します。

まず Modern Java Component Design with Spring Framework 4.3 に参加。

Spring Framework 4.3 の新機能を Java8 のモダンな書き方で紹介してくれました。見たこともない機能などはなかったので、4.3 の新機能は普通にここで確認すると良いでしょう。

ちなみにこの 4.3 は、 4系で最後のマイナーバージョンになり、2019年までサポートが続くそうです。 4.2 のサポートはまもなく終了。

VerUp の時期を見計らっていた人は頃合いですね。

High Performance Microservices with Ratpack and Spring Boot

High Performance Microservices with Ratpack and Spring Bootに途中参加。

Image may be NSFW.
Clik here to view.

このセッションはソースコードを見ながらの解説がメインでした。

Ratpack とは、 Netty ベースの新しい 軽量な Web アプリケーションフレームワークです。Java8 か Groovy で開発できます。

これと Spring Boot で 高性能な Microservice を、という題材なので、興味を惹かれますよね。

ソースコードは Github に上げてくれているので、ご覧になってみてはいかがでしょうか？

s1p-high-perf-microservices

README.md に EC2 のインスタンス別でベンチマークが載っていますが、ちょっと信じられないような数字です。

Twelve Factor, or Cloud Native Apps

午後は、 Spring Boot と Cloud Native により Twelve Factor App を満たす、という内容のセッションでした。
が、私の英語力と前提知識がなさすぎて、今いち理解ができない部分が多かったため、説明を割愛します。
セッション自体も10分程度で終了し、後は質疑応答、という簡単なものでした。

Testing Spring Boot Applications

最後は Testing Spring Boot Applications

Spring Boot 1.4ではテスト関連の機能がたくさん追加されましたね。

• 新しくなった @SpringBootTest
• RANDOM_PORT で実際に起動した HTTP サーバーのテスト
• @MockBean によるモッキング
• @DataJpaTest による in-memory DB でのテスト
• JSON のアサーション

といった機能の説明と実演をしてくれました。JSON のアサーション、毎回自分でゴリゴリ書くのは辛いので、地味だけど嬉しい機能ですね。

講演後は質疑応答の時間ですが、やはりテストコードは身近な問題なので、盛り上がってディスカッションのようになっていたのが印象的でした。

こちらも GitHub でコードが公開されています。

testing-spring-boot-applications

所感

最後に、海外のカンファレンスに初めて参加した立場から、感じたことを綴ってみます。

意外と忙しい

懇親会などは遅い時間まであり、また朝も早いので、時間の余裕はありません。

時差ボケも相まって、カンファレンス中にウトウトしてしまうこともしばしば。

時間管理をしっかりしないと大変です。

実はこの記事を書いている今も既に 2:30am... orz

会場が寒い

真夏のラスベガスなので、日中の外気温は40℃にも達しますが、会場内は冷房が効きすぎていて寒いです。

事前に参加経験者から忠告を聞いて用心していましたが、想像を超える寒さでした。

しかし現地の人はみんな半袖...

お祭り感がすごい

日本で開催される大きめのカンファレンスと比べても、演出が派手だったり、懇親会が豪華だったり、コミュニティが活性化するための努力が半端じゃないと感じます。お祭り感があってとても楽しいです。

ちなみに食事は朝昼晩すべてカンファレンス側が用意してくれます。贅沢ですね。

夜はお酒も出ます。

写真は、格闘ゲームで他国のエンジニアと交流する池田です。楽しそうですね。

Image may be NSFW.
Clik here to view.

書きたいことが多すぎて、取りとめのないエントリになりましたが、とにかく充実した時間を過ごせています。
エモいことも書きたい気分ですが、最終日も書く予定なので、今日はこのくらいで。

明日は池田の素晴らしい記事がありますので、期待していてくださいね。

秋葉原ラボの高野です。2016/07/29に日本心理学会第80回大会で村瀬美月氏、鈴木麗璽准教授、有田隆也教授（共に名古屋大学大学院情報科学研究科）との共同研究が発表されましたので、それについてご紹介いたします。

ソーシャルゲームでは、多くのヒトが思い思いに自由に行動した結果が詳細に記録されているため、ヒト行動の研究に有用です。これまで私たちはガールフレンド（仮）のデータを用いたヒトの協調行動について研究してきました（以下の関連発表を参照のこと）。本研究ではヒトの協調行動にコミュニケーションのタイプ（1対1、1対多、掲示板）が与える影響について知ることを目的として、そのデータを分析しました。その結果、1対1と1対多のコミュニケーションは協調行動に正の影響を与えることがわかりました。これはコミュニケーションの性質（時間的・心理的なコストなど）によってを効果が異なることを示唆します。また、社会関係の構築・維持におけるコミュニケーションの効果についても分析した結果を報告しました。

発表

• M. Murase, M. Takano, R. Suzuki, and T. Arita, "A statistical analysis of play data in a social network game: Effects of communication on cooperative behavior", 31st International Congress of Psychology (ICP2016), Poster Presentation in Japanese, RC-05-2, 2016.

関連発表

1. M. Takano, K. Wada, and I. Fukuda, "Reciprocal Altruism-based Cooperation in a Social Network Game", New Generation Computing, 34, pp. 257-271, 2016.

2. M. Takano, K. Wada, and I. Fukuda, "How Do Newcomers Blend into a Group?: Study on a Social Network Game", 3rd International Workshop on Data Oriented Constructive Mining and Multi-Agent Simulation (DOCMAS) & 7th International Workshop on Emergent Intelligence on Networked Agents (WEIN) (workshop at WI-IAT 2015), 2015.

3. M. Takano, K. Wada, and I. Fukuda, "Environmentally Driven Migration in a Social Network Game", Scientific Reports, 5, 12481; doi: 10.1038/srep12481 (2015).

4. 高野雅典, 和田計也, 福田一郎, "ソーシャルゲームプレイヤーの協調行動の分析", 人工知能, Vol. 30, No. 1, pp. 74-82, 2015.

参考

• 秋葉原ラボ 発表一覧

どうもこんにちは。先日に引き続き技術本部の池田 (@yukung) です。少し日が空いてしまいましたが、 SpringOne Platform 2日目のレポートをお送りします。

他にもたくさんのセッションがありましたが、今回は私が聴講したセッションを中心にお届けします。セッション一覧はこちらです。

Main Stage

1日目と同様、冒頭は Main Stage という Keynotes セッションでした。
Image may be NSFW.
Clik here to view.

Keynotes 前半

主に前半は Cloud Foundry や OSS, Community の話や、ユーザーである Bloomberg, McKesson, Manulife といった企業がいかにしてソフトウェアを中心にした企業文化に変えていったのかといった culture の話、そして Cloud Foundry と Google, Microsoft, Accenture が協力関係を持ちながらどういった取り組みをしているのか、という話がありました。

個人的には Bloomberg, McKesson といった企業の企業文化の変革のエピソードは興味深く、 Bloomberg は production 環境に1日に 4000 デプロイしていたり、まずプロジェクトに CONTRIBUTE.md を作るようにして、 Pull Request を推奨するようにして社内に OSS のコントリビュート文化を取り入れるように変えていったそうです。 Mckesson は Fortune500 の5位に位置する企業ですが、彼らもまたソフトウェア中心の企業文化を強くアピールしていました。Marc Andreessen の

“ソフトウェアは世界を食う”

という言葉を引用しながら、 Uber, Facebook, Square, Twitter などのように、現在では既存のビジネスをソフトウェア中心の企業が食っていっている、コードはビジネスのために書くのだ、そしてビジネスロジックに集中し、生産性を上げろ、クリエイティビティを上げろ、そのために Spring Boot や Spring Cloud は強い味方となるだろう、という強いメッセージを発していました。"Embrace Software Driven Mindset." とも。

私が聞いていて特に感じたのは、どの企業も技術者だけではなく、ビジネスレイヤーの人たちがソフトウェアや技術に対してビジネスそのものだ、という強い意識を持っていて、ビジネスのスピードを上げるために Cloud Native や Microservices にするんだ、という考えを持って、トップダウンでそういう方向に舵を切っていっていることに驚きました。この辺りは、個人的に日本との違いを感じるところです。

Main Stage 後半

よりテクニカルな話になり、Spring 5 のロードマップや、今後出てくるであろう Java 9 との関係が話されました。 DI コンテナ内部の改善の話や、 Web アプリケーションをより効率的にする仕組みである HTTP2, Reactive Streams ベースのコントローラの導入、Lambda-oriented な HTTP ルーティングや処理の導入など、Spring Framework がより進化していくことを印象づける話でした。JDK9 については、おそらくスケジュールは遅れるものの、 Spring Framework 5.1 で JDK9 をフルサポートするそうです。

その後、 Spring5 の目玉の一つである Reactive Streams 対応についてクローズアップした話がありました。HTTP リクエストを捌くためにスケーラブルにするためのアーキテクチャモデルの変遷（古くは1リクエスト1プロセスの時代から、1リクエスト1スレッド、ロードバランサでの分散処理、そしてクラウド上での水平スケーリングへ）を前提にして、現在ではクラウド上で効率的にリソースを利用して elastic なスケーリングを実現したいはずが、現実はうまく行っていなかったり、コストが掛かってしまっているといった問題があるのではないか、という問題提起がありました。

そこで対応する一つの方法として、クラシックなサーブレットコンテナが提供する様なスレッドモデルではなく、Netty や Node.js でポピュラーとなった少ないスレッド数でも多くの処理が行えるノンブロッキングなランタイムでアプリケーションを開発することで、リソースが節約でき、より効率的にできるのではないかということでした。いわゆる C10K 問題の話ですね。

ただ、ノンブロッキングなプログラミングモデルはコールバックヘルに陥りがちで複雑になりやすいですが、Java8 で登場した java.util.concurrent.CompletionStage を使うことで宣言的に非同期処理を記述できるようになり、さらに java.util.stream.Stream を使うことでコレクションやストリームデータをうまく扱えるようになりました。ただそこに欠けていたのは、Java9 で標準化予定の Reactive Streams の仕様策定にも関わっている Doug Lea が言及した、アクティブになったデータを push スタイルの操作で、そこを補完するのが Reactive Streams である、という説明がありました。

Reactive Streams はとても小さくてシンプルな仕様で、登場するのは Publisher と Subscriber しかおらず、そこに Subscriber からのボリュームコントロールを行う Buckpressure があるだけであるということ、そしてそれらがパイプラインのようにコンポーネント間を繋いでくれるということが説明されました。

Spring5 ではこれを Project Reactor で実現しようとしています。Project Reactor では、Reactive な Data Type として Mono と Flux という型が提供され、 Mono が CompletionStage に当たるもので、Flux は Stream のように複数のストリームデータを扱うためのモデルになります。そしてこの Mono と Flux が、Spring エコシステムの中で複数のマイクロサービス間や分散データストアやメッセージブローカーを介して繋がり、全てがデータのストリームで表現できるようになる、というのが Spring5 で実現しようとしている世界である、というメッセージでした。

では具体的に Spring5 でどの辺りが変わるのかについては、以下の図がわかりやすいと思います。

Image may be NSFW.
Clik here to view.

Spring MVC での Controller のリクエストハンドラで、Reactive Type である Mono, Flux が引数や戻り値で扱えるようになる Spring Web Reactive が新しく提供されます。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

これはまた RxJava とも互換性があります。

Image may be NSFW.
Clik here to view.

REST API から別のエンドポイントを叩く例では以下のように記述することができます。

Image may be NSFW.
Clik here to view.

また、それに伴って、HTTP リクエスト／レスポンスの読み書きに Reactive な HTTP API が使われるようになり、InputStream/OutputStream が Flux や DataBuffer などで表現され、HTTP ソケットとのやりとりが Backpressure 付きで扱えるようになります。

そして、それらの基盤となるサーブレットコンテナでは、ノンブロッキング I/O が利用可能になった Servlet 3.1 Container の Tomcat/Jetty だけでなく、Java でノンブロッキング I/O の先駆けであり、サーブレットコンテナではないランタイムである Netty や、同じくノンブロッキング I/O をサポートするWebコンテナの Undertow が Spring5 でサポートされます。

最後に、Reactive Streams 対応がその他の Spring プロダクトにどういう効果をもたらすかに触れ、例で上がっていたのは Spring Cloud Stream というマイクロサービス間のメッセージングを実現するフレームワークでも、Reactive な Type で input/output を扱うことで、同様に Reactive なプログラミングモデルで記述することができるとのことでした。

Image may be NSFW.
Clik here to view.

後半の Technical Keynote は、Spring エコシステムがどういう方向に向かっているかということを知ることで、自ずと Reactive Streams や Microservices、分散メッセージング等の技術がどう繋がっていくのかが想像できる話で、個人的にとても得るものが多かったです。この辺りについて詳しくは

• https://spring.io/blog/2016/04/19/understanding-reactive-types

に記載されています。また日本語の資料としては @making さんの JJUG CCC 2015  Fall の資料がとても理解しやすいです。

Putting a SpEL on Spinnaker: Evolving an Expression Language for Continuous Delivery at Netflix

• Session Abstraction

Spring Framework で利用できる式言語である SpEL(Spring Expression Language) を、Netflix OSS でも有名な Spinnaker で、パイプライン記述言語としてどのように使っているか、というセッションでした。 SpEL は他にはテンプレートエンジンの Thymeleaf でも使えることで知られていると思います。

Spinnaker は、マルチクラウド対応のインフラ・アプリのデプロイとクラスタ管理を実現し、継続的デリバリを自動化するソフトウェアです。Netflix は AWS のデプロイ・継続的デリバリの実現に Asgard という OSS を提供していましたが、その後継となるものです。

Spinnaker では、デプロイパイプラインを定義する際のステップの条件記述や、デプロイ単位のスタックの指定に SpEL で指定することができ、柔軟な記述が動的にできるとのことでした。動的に記述できることで記述量が減らせるので、パイプラインの定義がより気楽に行える、ということでしょうか。

また、セッション中のデモではインフラのデリバリを Jenkins のビルドパイプラインで構成して、AMI を指定して SpEL で記述されたコンフィグパラメータをインジェクションして、インスタンスの生成、テスト、Production への投入を自動化する例を実演していました。さらに SpEL の便利な使い方として、 Spinnaker では #alphanumerical や #fromUrl、#stage などのヘルパー関数を提供して、より簡単にかつパラメータチェックなども行えるようにしている、と言っていました。また、デモの中で、先日 Netflix からリリースされたマイクロサービスを可視化する Vizceral のデモをしていましたが、個人的にはこっちの方に興味を引かれてしまいましたｗ

• https://twitter.com/yukung/status/760911953120272384

Spinnaker の Pipeline Expressions のドキュメントはこちらにあるので、興味がある方はどうぞ見てみてください。

Architecting for Cloud Native Data: Data Microservices Done Right Using Spring Cloud

• Session Abstraction

Data Microservices というデータに着目したマイクロサービスアーキテクチャを、Spring Cloud Data Flow と Spring Cloud Stream を使って実現するというセッションでした。

Data Microservices は、このセッションだけでなく他のセッションでも頻繁に聞かれたキーワードでしたが、このセッションで Data Microservices とはどんなものかイメージすることができました。マイクロサービスアーキテクチャと聞いてよくイメージされる、モノリシックなアプリケーションを分割したシステム的なアーキテクチャのコンセプトを、データ処理のプロセスも同じように適用します。モノリシックな1枚岩のデータ処理プロセスではなく、小さいプロセスを組み合わせることで、データを加工するプロセスをより迅速に開発し、リアルタイムにユーザに分析結果をフィードバックできるように、というのが Data Microservices のコンセプトだと思います。

コンウェイの法則で語られるように組織ごとにマイクロサービス化が進んでいっても、連携するシステムは相変わらずモノリシックだったり巨大なシステムが残り、それらを Integration Bus や ESB(Enterprise Service Bus) などで繋ぎ、ETL ミドルウェアで集約しデータ・ウェアハウスなどに蓄積するのが典型的なデータ分析のアーキテクチャですが、これは高価なソリューションであることが多く、また、夜間バッチなどで頑張って計算を行っているのが実情で、夜間バッチが遅れたりすれば分析業務にも影響が出ますし、リアルタイムな分析や機械学習は難しいという問題があります。

Image may be NSFW.
Clik here to view.

そこで Data Microservices では、モノリシックなデータ処理プロセスの一つ一つを分解し、それぞれをマイクロサービス化することで、迅速なデプロイや Blue-Green デプロイメントを可能にし、デリバリ速度を上げる事でデータ分析の精度を上げることができるということでした。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

具体的には、一つ一つのデータ処理プロセスは Spring Boot のプロセスでマイクロサービス化し、それぞれのプロセス間や、メッセージキューなどの各種ミドルウェアとのメッセージングを Spring Cloud Stream で簡単に統合することができるそうです。

Image may be NSFW.
Clik here to view.

そしてこれらをクラウド上で実現することで、メトリクスやモニタリング、ログの集約やオートスケーリング、自動回復なども実現できるとも付け加えていました。また、データ処理パイプラインを Spring Cloud Data Flow を使って定義することで、それぞれのデータ処理プロセスをオーケストレーションすることができるようです。

Image may be NSFW.
Clik here to view.

ここまで説明したところで、デモとしてリアルタイムに入ってくる POS データを元にして機械学習を通して決済結果のリスク分析を行い、結果をリアルタイムにブラウザに出力するデモを披露していました。

デモ風景

Image may be NSFW.
Clik here to view.

デモのアーキテクチャ

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

こうした Spring Cloud Stream/Spring Cloud Data Flow を使ったアーキテクチャの全体像がこちらで、Business Microservices と Data Microservices とに分けられているのが特徴的です。

Image may be NSFW.
Clik here to view.

個人的にこの図を見た時に、Main Stage で紹介されていた Spring5 の Reactive Streams が目指す全てをストリームで扱える、という世界が具体的なイメージとして自分の頭の中に入ってきた感じがしました。

今回のデモはソースコードが GitHub にありますので、興味があれば是非読んでみてください。

Wall St. Derivative Risk Solutions Using Geode

• Session Abstraction

ウォール街のデリバティブ取引のリスク分析に Apache Geode を使っている事例のセッションでした。が、ちょっと専門用語が多く、またスピーカーの喋り方がくぐもった声で聞き取りづらかったことで、あまり理解することができませんでした。。。そのうちセッションの動画が公開されると思うので、その際にまた見なおしてみたいと思います。Apache Geode 自体は、インメモリデータグリッドのソフトウェアで高速＆スケーラブルである、ということくらいしかまだ知識がなかったのですが、セッション中で相当量のトランザクションを捌いている話をしていたと思うので、今後自分でも触ってみたいと思っています。

Cloud Native Streaming and Event-Driven Microservices

• Session Abstraction

マイクロサービス間のメッセージングを行うフレームワークとしての Spring Cloud Stream の紹介と、その中身や仕組みについてコードやデモを交えて説明されていたセッションでした。上記で紹介した Data Microservices のセッションを見て、マイクロサービス間のメッセージングについてより興味が出てきていたため、Spring Cloud Stream の理解を深めるのにちょうどよいセッションでした。資料が公開されていましたので貼っておきます。

基本的には、Spring お得意のアノテーションを使って、メッセージの input/output を簡単に指定でき、具体的なメッセージングミドルウェアの実装も binder という概念で扱えるため、様々なメッセージングミドルウェアを透過的に扱える、という感じでしょうか。Spring Boot が基盤となっているため、アプリケーションを作るのも楽ちんなのが良いですね。

現在 Production Ready なミドルウェアとして、Apache Kafka や Rabbit MQ がサポートされており、Experimental ではありますが JMS や Google PubSub もサポートされているようです。他にも consumer ごとのグルーピングやパーティショニングなどもできるようです。セッションの最後に、Spring Cloud Stream 1.1 でサポートされる機能や、様々なデータソースのスキーマをバージョン管理する schema evolution の紹介や、将来的な展望も紹介されていました。

マイクロサービス化を進めていくと、この辺のメッセージングの仕組みも必要になってくると思うので、Spring Boot 同様、基盤となるソフトウェアになっていくかもしれないので、今後キャッチアップしていきたいですね。

Transforming the Monolith at 20M tph

• Session Abstraction

2日目最後は、Comcast というケーブルテレビ・インターネットプロバイダの事業を行っている企業のマイクロサービス化の事例セッションを聴講しました。

内容としては、よく日本でも聞くような話でした。2億5000万/日の大規模トランザクションでかつ500台以上のサーバを抱える中で、以下の様な問題に直面したそうです。

• レガシーなコードベース
• 人手での手動オペレーション
• 物理インフラ
• ぐちゃぐちゃに混じりあったデータ
• 開発速度が出ない

これだけでもどこかで聞いた話だなぁと思うわけですがｗ そんな中、Comcast は一つは文化的な側面、もう一つは技術的な側面という2つのアプローチで組織を変革していったそうです。

文化的な側面では、Dev, Ops, QA それぞれの間にあった壁を壊すために、一つのチームにそれぞれの役割を含むように変え、自己組織化を促していったそうです。

技術的な側面では、マイクロサービス化を進めていくとともに、データの責務を分けて整理したこと、そしてテクノロジースタックも

• Weblogic -> CloudFoundry
• Oracle -> Couchbase
• IPベースのルーティング -> Consumer ベースのルーティング

に変えていき、CI やデプロイも

• Jenkins -> GoCD
• Maven -> Gradle
• 自作スクリプト -> Continous Delivery

というモダンなものに変えていったそうです。

そうした変化が、現在では CloudFoundry 上でゼロダウンタイムデプロイを実現するプラグインや Canary デプロイメントを実現するプラグインを開発して OSS で公開するまでになったそうで、そうした成果は GitHub で公開されています。将来的には外部サービスの影響をさらに縮小し、より多くのサービスを CloudFoundry 上に持って行きたいとのことで、これからさらにマイクロサービス化を進めていくことが印象的でした。

個人的な印象として、アメリカでは AWS や Netflix の事例がよく挙げられるために企業のマイクロサービス化が大分進んでいるのだろうという思い込みがあったのですが、このセッションの他にもいくつかセッションを聞いていく中で、アメリカでもまだまだこれからマイクロサービス化しようとしている、もしくは現在進めている、という企業が多いことを知りました。こういう感覚を現地で知ることができたことも、今回来て良かったなぁと思うところでした。

2日目の感想

全体を通して、 Microservices と Reactive Streams、Data streaming, Messaging などが強調されたセッションが多かったと思います。そしてそれらをサポートするミドルウェアとしての Kafka や Geode, 統合するフレームワークとしての Spring Cloud が今後より進化していくことが印象的でした。これらの技術要素が結びついていくことが実感として感じられたことが、今日の大きな収穫です。

ただ大分広範囲に渡って色々出てきたので、日本に帰ってからキャッチアップするものがたくさんあって大変だなぁというｗ あと結構2日目も一日セッションだったので大分疲れました。部屋に戻ってから寝オチしていたのは内緒です。

明日は最終日ですが、まだまだ興味深いセッションが多いので明日も頑張ってレポートしたいと思います！

サイバーエージェント公式エンジニアブログをご覧の皆さんこんばんは、技術本部サービスリライアビリティグループの須藤(@strsk)です。最近2016年で3回目の役満、大三元を和がりました。

Image may be NSFW.
Clik here to view.

本日は、9月6日に行われたGCP NEXT World Tour Tokyoにて発表した資料を公開します。

技術本部 Advanced Dev.Center（略してADC）の村上です。

私達はMake Your Goals Come True. Easier + Faster. 

をコンセプトに開発環境の改善や統一化を行ってます。

タイトルのとおり、私達の組織ではソースコードのバージョン管理システムとしてGithub Enterprise（以下GHE）を導入しており、今回久しぶりにアップデートを行ったので、それについて書かせていただきます。

なお、今回の作業にはADCメンバーに加え、敏腕インフラエンジニアの@kakerukaeruさんのお力添えあってこそということを彼の上司@strskへ向けてアピールしておきます。

規模・SPEC

規模感としてはユーザ数は約1000名、Organization約400、Repository約10,000になります。

- Primary on AWS EC2

Instance Type :r3.4xlarge

EBS(root device) :100GiB

EBS(block device) :1500GiB

- Replica on AWS EC2

Instance Type :r3.4xlarge

EBS(root device) :60GiB

EBS(block device) :1500GiB

アップデート方針決め

アップデート前のバージョンはVersion 2.2.7で、アップデート検討中にVersion2.7が発表されたのですが、発表されたばかりだったため2.7系へのアップデートは行わず、2.6系に留めることにしました。

今回Version 2.6.8にアップデートしたわけですが、GHEの仕様上、アップデートは現在のバージョン(v2.2.7)から最新バージョン(v2.6.8)まで一気に行うことはできないので、いったん2.4系へアップデートしてから2.6系へアップデートする手順を踏んでいます。

今回の作業で最も注意を払った点は

・会社の資産であるソースコードや付随データを失わないこと

・サービスに支障をきたさないこと

なので万が一のことを考えいつでも戻せるような手順を事前検証を行いつつ、何度も考えては議論しました。

Image may be NSFW.
Clik here to view.結論

・アップデート前のプライマリはアップデート後もそのまま残しておいて、いつでも元のバージョンへ戻せるようにしておく。

・アップデートするのはレプリカのみとする。アップデート後は本番のElasticIPを付け替えて本番として利用する。

・新プライマリ、旧プライマリのそれぞれには新規でレプリカを用意する。

Image may be NSFW.
Clik here to view.

事前検証＆準備

主に検証したのは以下になります。

・インスタンス作成〜レプリケーション

・リストア検証、snapshotからの再構築
今回は切り戻しをしないので本手順は発生しませんが、再現性の確認のため実施。

・プライマリとレプリカの設定ファイルの比較

$ ssh -p122 admin@hostname -- 'ghe-config -l'

でCLIから設定の確認ができます。

アップデート前はv2.2だったのでレプリカとの設定ファイルの結構差分がありました。

・backupUtilsの更新

githubの公式ツールであるbackupUtilsが古くなっていたので更新。

・EBS snapshotの作成

snapshotは差分バックアップなので、事前に実行しておくとメンテナンス時間中のバックアップが短くてすみます。

手順

・メンテナンス開始告知

・メンテナンスモードに入れ、ユーザアクセス遮断

・バックアップ（ backup-utiles及び EBSスナップショット）を取得

・レプリカとプライマリのレプリケーションを切断

・レプリカのSettingsをプライマリと同じにする

・レプリカをアップデート（v2.2.7 -> 2.4.9 -> 2.6.8)

2.2.7 -> 2.4.9は約1時間、2.4.9 -> 2.6.8は約40分かかりました。

・新しくレプリカ機を用意しレプリケーション開始

・プライマリとレプリカのElasticIPを付け替える

この作業により、DNS更新なしにレプリカを本番に置き換えることができますし、万が一の場合も即時元のバージョンへ戻すことができます。

・メンテナンスモードを解除

確認コマンド

アップデート前後でのrepoやorganizationデータの比較に利用したAdmin用APIは下記になります。

- Repository listhttp(s)://<hostname>/stafftools/reports/all_repositories.csv- Organizations listhttp(s)://<hostname>/stafftools/reports/all_organizations.csv- Gist list（only public）http(s)://<hostname>/api/v3/gists/public- number of issue, hook, milestone, orgs, repost, comment etchttp(s)://<hostname>/api/v3/enterprise/stats/all

アップデート後

1. pull requestが消えた!?

メンテナンス終了後、業務開始時間になると、pull requestが表示されないとの報告が続々と寄せられました。

アップデート前後のpull request数の変化はなく、詳細に確認してみるとlistの表示だけに問題があることがわかりました。結果としてindex作成が終わっていないことが原因でした。その後もindex作成は完了せず、結局、16時間後に確認した時点で80%弱の進捗でした。

翌朝ようやくIndex再構築の完了が確認でき、pull requestのリスト表示は正常に戻りました。次回のアップデートでは事前に周知しておきたいです。

2. deploy keyが消えた!?

GHEの仕様でdeploy keyはrepository毎に設定してくださいというアナウンスをしていましたが、事実上2.2系では同じorganization内であればdeploy keyの使い回しができてしまっていました。v2.4にバージョンアップしたことで仕様に忠実(？)になり、その使い回しができなくなったようです。

https://enterprise.github.com/releases/2.4.0/notes

正しい挙動になったということなのですが、一部利用者間で混乱が発生する事態になりました。repository数が多いプロジェクト救済のため、MachineUserの運用も検討しましたが、複数のデメリットが払拭できず見送ることにしました。
GHEへMachineUserの運用について問い合わせたところ、issueは上がっているものの、現行、一般ユーザと権限・コスト両面で同様の取り扱いということでしたので、改善を待ちたいです。

3. markdownの画像が表示されない!?

バージョン2.6からW3Cのレコメンドに従い、HTTPSコンテンツ上のHTTPコンテンツ（いわゆるmixed content）はブロックするように仕様変更されていました。

なので2.6以降使えなくなっています。

https://enterprise.github.com/releases/2.6.0/notes

4. やっぱり古いバージョンを残しておいて良かった

こちらは頃合いをみて削除予定ですが、アップデート後はたくさんの方が検証するために、アップデートとは無関係の事象も報告されたりするので、問題の切り分けのためにも残しておいてよかったと思いました。また、いざという時はこっちにそのままのデータがあるという安心感も大きいです。

これから

未解決の問題もまだ残っており、新機能の検証、バイナリデータの管理等改善したい項目が日々生まれている状況です。全サービスのエンジニアと協力し合いながら、快適な開発環境の提供をチームで取り組んでいきます。

いつもADCに協力してくれるエンジニア・クリエイターの皆様、いつもありがとうございます。皆様の激励が我々の励みになっています。

また今回の記事が同じような開発環境を担当している方々の参考になれば幸いです。
 

こんにちは
株式会社AbemaTVのAbemaTV FRESH!でフロントエンドの開発をしているすちをと申します。

今回は9月にオランダのアムステルダムで開催されたIBC2016（International Broadcast Conference）に参加してきましたのでその報告をさせていただきます。

IBCとは

もともとはヨーロッパ内の放送局向けに、放送分野を中心とした映像・音響技術の展示会として開催されはじめたイベントですが、近年ではそれに加えインターネット配信に纏わる幅広い最新テクノロジーのアピール場所となっています。今年は世界各国から1,600を超える出展がありました。

会場

Image may be NSFW.
Clik here to view.

毎年RAI(東京でいうビックサイト・大阪でいうインデックス)という会場で開催されています。

Image may be NSFW.
Clik here to view.

会場内はジャンルごとに14のセクションへと分かれていています。

中央にある3のホールでは期間中講演が行われていました。

ご覧の通り広大で、何回も迷子になってしまいました。

Image may be NSFW.
Clik here to view.

ゲート付近の端末で事前に予約しておいたメール内のQRコードを読み取ると、プリンターから入場カードが印刷されます。

ブース

今回見たブースの中で特に気になったものを紹介していきます。

IBM

Image may be NSFW.
Clik here to view.Martin Runde@emrunde 

#IBM zeigt #cloud video Lösungen auf der #IBC2016 in Amsterdam #ibmcloudde https://t.co/t0EcCT1N4f

2016年09月12日 22:33

ブースの写真を撮り忘れたので拝借させていただきました。

Image may be NSFW.
Clik here to view.

IBMが開発している自然言語処理のWatsonを用いて、テニスのUSオープン映像に含まれている音声を字幕におこすデモが展示されていました。

サンプルをみていただくとわかると思いますが、Confidenceは70〜90%台とほぼ正確に字幕として表示されています。

実際にBluemixから使用が可能となっており、日本語にも対応している所が驚きでした。

Adobe

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Adobe CCに搭載される新機能の発表と共にデモが行われていました。

私が聞いた内容としてはAbode Premiereで

• チームプロジェクト機能が強化される
• ファイルはローカルではなくクラウド上で管理される
• アプリケーション内でチャットのように共有作業者を招待できる

というものでした。

これまでは1人の作業データをクラウドで扱うという感じでしたが、これからは複数人がクラウド上で同時に作業を行えるというAdobeのアナウンスでした。

詳しくはコチラにまとめられていたので気になる方は見てみて下さい。

Crevo

Image may be NSFW.
Clik here to view.

FRESH!の配信でも使用されているLiveShellは配信時に映像リソース(カメラなど)からHDMI経由でLiveShell端末を繋ぐことによってそのまま配信サーバーに映像を飛ばす事ができるデバイスです。(=PCを使わずに配信できるのがメリット)

こちらで新しく展示してあったLiveShell.Xは1080p/60fpsでの生配信が可能なものなので将来的にはFRESH!でもこのレベルの画質で遅延なく配信できればいいなと感じました。

Image may be NSFW.
Clik here to view.Engadget Japanese@engadgetjp 

一般向けモデルとしては最高クラスの機種です。 / Cerevoのライブ配信機材「LiveShell.X」はプロの現場でどこまで使えるのか？ 岩佐社長のインタビュー動画付き - Engadget Japanese https://t.co/7krbISpM36

2016年09月17日 05:33

Peer5 Happy Our

Image may be NSFW.
Clik here to view.

夕方からは徐々に各ブースで🍺や🍷が配られるようになり参加者やブースの出展者が交流を深める時間となります。

私もHls.jsの作者である@manguiさんとお話をしました。(Peer5のブースでした)

FRESH!では数ヶ月前から一部のブラウザでHls.jsを使用しており、manguiさんが「最近TwitterでHls.jsと検索するとよく日本語のツイートでAbemaと引っかかるようになったがお前のとこか」の様なことを言っていましたw

各国のエンジニアたちもクロスブラウザでのHLS(HTTP Live Streaming)再生に疲弊しているようで、デンマークから来たエンジニアはその場で1時間くらいmanguiさんにWebVTTの質問をしていました。

所感

知らないことが多かった

今回このIBCに参加して心に残ったことは自分の知らない発見がたくさんあったことでした。映像という分野において4K、HDR、VRなどの技術をどうWebの中で表現していくか注視していきたいと思います。またOTTの台頭によってインターネット動画の機運が世界的に急速に高まっていることも身にしみて感じました。Image may be NSFW.
Clik here to view.

つたない英語でも親身に受け答えしてもらえた

IBCに参加されている方は皆さん優しく、私みたいな英語スキルの低い日本人の質問にも耳を傾けてくださいました。それ故、今回来ていたヨーロッパ各国のエンジニアと同じくらいスムーズに議論できるようにならないとと痛感しました。

Image may be NSFW.
Clik here to view.

アムステルダムはすごいいいところだった

コンパクトな街で市内であれば自転車やロードバイクでアクセスできそうな感じでした。Heinekenがものすごく安くかったです。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

技術本部 Advanced Dev.Center（略してADC）の大倉です。

私達は、Make Your Goals Come True. Easier + Faster. 、をコンセプトに1600人規模の開発環境の改善や統一化を行ってます。

この記事は、CircleCI Enterprise管理者を対象としております。今後、導入を予定されている管理者の方にとって、少しでも有益な情報になればと思います。

CircleCI kim様、kevin様、いつも迅速なサポートありがとうございます。とても感謝しております。

CircleCI kim, kevin

Thank you very much always for your cooperation !

なぜ、オンプレ化したか

当初のEnterprise版は.com版と同じようにクラウドサービスとして展開されていましたが、2016年にCircleCI Enterpriseのビジネスモデルに更新が入ったことで、

たとえば、継続してクラウドサービスとして利用する場合、

• 高額（前年度比較７倍弱）の更新費用がかかる
• iOS用のビルド・テスト環境が利用できない

という状況になったことが主な理由です。

オンプレ化のメリット／デメリット

• メリット

次章”アーキテクチャ詳細図”のようなサーバー構成にしたところ、ビルド及びテスト処理速度が速くなりました。つまり、サーバー構成をカスタマイズできる点が

大きなメリットでしょうか。また、ビルドイメージをサービス仕様に合わせてカスタマイズすることもできるので、より処理速度を速くできるという点もあります。

• デメリット

サーバー構成やビルドイメージをカスタマイズできるメリットの代わりに、それを運用・管理する困難さが管理者に発生します。Enterprise版は発展途上なので、管理者向けのドキュメントやノウハウは、利用者向けのドキュメントと比較するとかなり少ない状況ですので、CircleCIのエンジニアと情報共有をしながら、BugFixしてもらいながら、運用・管理する必要があります。

アーキテクチャ詳細図

Image may be NSFW.
Clik here to view.

基本、GithubEnterpriseへのPush→（トリガー）→CircleCIEntrepriseでJobを実行 → 結果をSlackへ送信
といったCI環境を構成しています。CircleCIEntrepriseはymlの設定だけでCI環境を得ることができるため、プロジェクト毎にサーバを用意することなく、属人的作業も排除することが出来、サービス品質を維持していく上で重要な役割を担っています。

"Immutable Infrastructure"という設計

BuilderBoxは基本使い捨てする設計（Immutable Infrastructure）で提供されているのですが、弊社のOn-Premise（OpenStack）環境では、インスタンスを使い捨てるような設計にすることが厳しかったので、LXCコンテナデータを削除し、コンテナイメージを再ダウンロードすることで、LXCコンテナを使い捨てる（初期化する）ことにしました。

$vi /etc/init/circle-image.conf---> 9行目のmanualをコメントアウト#manual<---$ sudo service circle-image start$ sudo tail -f /var/log/upstart/circle-image.log〜省略〜+ curl -sSL -o /mnt/tmp/container.tar.gz https://circleci-enterprise-assets-us-east-1.s3.amazonaws.com/containers/circleci-precise-container_0.0.1338.tar.gz+ untar_image /mnt/slave-image+ SUBVOLUME=/mnt/slave-image+ sudo -n btrfs subvolume create /mnt/slave-imageCreate subvolume '/mnt/slave-image'+ sudo -n tar -xp --use-compress-program=pigz -f /mnt/tmp/container.tar.gz -C /mnt/slave-image --numeric-owner

監視（CLITICAL）

主に監視をしているのは以下の項目です。

• ServiceBox（cpu, disk, url（https://{circleci-url}) , load , ntp, docker containers）
• BuilderBox（“Fleet State = not-healthy”, “queue total wait time per instance" and "leaked error at a container”）

監視をする上で利用しているREST APIは、この辺でしょうか。

※非公式APIも含まれますのでUpdateにより利用できなくなる可能性があります。

• https://{CIRCLECI URL}/api/v1/admin/build-state-summary
• https://{CIRCLECI URL}//api/v1/admin/build-state
• https://{CIRCLECI URL}//api/v1/admin/recent-builds?shallow=true&offset=0&limit=100
• https://{CIRCLECI URL}//api/v1/admin/users?circle-token={TOKEN_CODE}
• https://{CIRCLECI URL}//api/v1/admin/recent-builds

スケールアウト

（アーティファクトを保存する先としては、AWS S3を利用してるため）スケールアウトはBuilderBoxのみ考えれば問題ありません。

free / busy コンテナの数をグラフ化し、以下のようにグラフが交差したときに弊社では2インスタンス（6コンテナ）追加しました。

Image may be NSFW.
Clik here to view.

コンテナ

コンテナは、Javaプラットフォーム上にClojureで作られているようです。

$ lein repl :connect 6005

で対話式に設定変更が可能ですが、通常アクセスする必要はありません。

（弊社ではDebugするためにCircleCI様の元でアクセスすることはありましたが）

なお、Javaプロセスは、以下のように起動しています。

sudo -E -u ubuntu java -Djava.net.preferIPv4Stack=true -server -XX:+UseConcMarkSweepGC -Xss1m -Xmx4g -Xverify:none -XX:+CMSClassUnloadingEnabled -Dfile.encoding=UTF-8 -jar /var/cache/circle-builder/circle.jar

はまったところ

ステージング環境ではまったのですが、NTPの時刻がServiceBoxとBuilderBoxで合ってないとServiceBoxにてBuilderBoxが正常に認識されないということがありました。

ステージング環境でも最低限の監視は入れたほうがいいですね。

おわりに

CircleCIでは、.comの運用をAWSで行っているからかAWSを基本とした設計になっています。予算に余裕があれば、オンプレ化するなら、AWSをおすすめします。

また、発展途上のツールなので、最新のバージョンにしておいたほうがBugを踏まなくて済みます。

参考URL

• https://circleci.com/docs/enterprise/

• https://enterprise-docs.circleci.com/

こんにちは。サイバーエージェント17卒内定者で現在アメーバブログでアルバイトをさせていただいている柳耕太です。
少し日は空いてしまいましたが先日行われたHTML5 CONFERENCE 2016のレポートを書かせて頂きました。

基調講演

基調講演前半

基調講演は前後半に別れており、前半は慶應義塾大学環境情報学部教授でW3Cサイトマネージャーでもある中村 修教授が登壇しました。

中村教授はWEBというものが世の中に現存する媒体（雑誌、カタログ、ニュース)を表現するものにとどまるのではなく、新しいデバイスやデータの扱い方等をハンドリングしてユーザーに提供しなければならない。といった今後進化する技術にWEBが対応すべきであるという話、そして最近よく聞かれる IoT, ビックデータ, 人工知能等 という技術はWEBという基盤の上に成り立っているものであり、地球を取り巻く大規模なOSと化しているWEBが抱えている問題を解消するために行われている活動や作業についてのお話をしていました。
 

ものすごくスケールの大きな話で、自分も含めホールでお話を聞いていた全員がWEBが社会でも重要な役割を占めていることを再認識していました。

[動画]

基調講演後半

後半にはGoogleでChrome開発に携わった経験を持つIncrements株式会社の及川卓也さんが登壇しました。

及川さんは アプリケーションとしてのWEB, メディアとしてのWEB, 基盤技術としてのWEB, といった3つの側面から見たWEBについて以下のことをお話していました。

1. 紙としてのメディアを超えたコンテンツにするためのAPIが増えてきている
2. 現代人はスキマ時間でスマホをいじるようになりニュースキュレーションサイト等の利用が増えているが、WEBには純粋なコンテンツ意外のリソースや外部リソースなどが多いのでアプリに流れがちといった今のWEBの問題点
3. WEBがこれからも重要であり続けるために、一旦立ち戻って「WEBに再投資すること」さらには「WEBを再発明すること」で正しい技術の発展の仕方を考えるべきである

そして、WEB広告の問題点を解消するためにAMPというものがあるが、CMSやツールなどが対応を阻害し対応したくても対応出来ない会社も多いというWEBの進化を阻害する要素についてもお話してくれました。

WEBの光と影をわかりやすく説明していただけたので、今現在どういうことが問題になっていて、どういう対策が講じられているのかがよく分かるお話でした。

[動画]

Reactの最新動向とベストプラクティス（株式会社TOLOT:小林 徹）

近年良く耳にするFacebook制製のJSライブラリ「React」がどういったプロダクトに使われているのか、Reactの歴史、Reactの特徴などを話した後、開発をサポートするツールについてやアップデートの際、破壊的な変更は無く非推奨のメソッドなどは1つ前のメジャーバージョンで警告をしてから廃止される。といったReactを実際のプロジェクトに組み込む際に気になる部分についても触れてくれました。

そして、今後はDOMの差分の検出・適応が同期的に行われているものを、優先度の高い処理と低い処理のレンダリング方法を変えるためにアルゴリズムの全面書き換えが行われていると言ったこれからのReactについてもお話してくれました。

React.PureComponentがshouldComponentUpdateの書き間違えによる、データは更新されてるのに再レンダリングされないという罠にハマるのを解消してくれそうな存在だと感じました。（良くハマるのは自分だけでしょうか）

資料

HTML5/JSモバイルアプリ最前線 (アシアル:田中 正裕)

Stack Overflowが行っている普段どういう言語を使っているかという調査によると、JavaScriptは総合1位、フロントエンド開発1位、バックエンド開発1位となっているが、モバイル開発ではJSは全然人気では無いというお話をした後、JSでモバイル開発を行うためのソリューションの歴史のお話をしてくれました、その中でも Cordova, ReactNativeについて深掘りして話してくれました。

Cordovaはすでに太いレールが敷かれているが、新しさは無く動きは活発ではなく、React Nativeはみんながバラバラにレールを引いているが、刺激的で動きが活発であるというのが所感だそうです。

そして、Googleが提唱するProgressive Web Appsという開発パターンの特徴についてお話した後三者の比較をしてくれました。

[比較画像]
Image may be NSFW.
Clik here to view.

それぞれの技術について色々な側面からのお話が聞けて、JSモバイルアプリ開発を行う際、技術選定に困ったときに参考になるお話でした。

資料

Material Design を使ったマルチデバイスに対応するデザインの作り方（Google:鈴木 拓生）

現在、様々なデバイスでWEBページを表示できるが、デバイスによって見た目がバラバラでユーザー体験が統一化されていないのを解決するために「Material Design」というデザインフレームワークが誕生したというお話の後、Device metrics, Resizer, といったMaterial Designの考えを組み込んだレイアウトを考えるためのツールや Google Fonts, Noto Fonts, Material Icons, といったフォントやアイコンなども紹介してくれました。

そして、フレームワークを使うことをゴールとするのではなく、フレームワークを使った上で何をするかが大事である。とデザインフレームワークに縛られるのも良くないと話を締めくくりました。

今回のお話はこちらに書いてあることを抜粋したものだそうです。

用意されたUIを使うことでどうUXを向上させるかという部分に集中して考えることができるので、このようなデザインフレームワークがあるとものすごく助かります。

お話の中にもありましたが、デザインフレームワークに縛られるのではなくそれを使って何ができるのかを今後考えていきたいと思いました。

TechFeedのつくり方 - Angular2 / Webpack / Ionic2 / Cordova実践入門（株式会社オープンウェブ・テクノロジー:白石 俊平)

今後Webはコンポーネント指向になる!という断言からスライドが始まり、TechFeedというサービスを作るために何故 Cordova, Angular2, Ionic2, Webpack, といった技術を選定したかというお話をした後、どういう開発フローで開発が行われているのかというお話をしていました。この開発のメリットとしては、Web, iOS, Androidのコードが統一できるため１人のエンジニアが横断的に様々なデバイスに携われることですが、１人のエンジニアが全デバイスの面倒を見なければならなくなるというデメリットもあるというお話もしてくれました。

そして、今回開発に使用した Cordova, Angular2, Ionic2, Webpack, について実際に開発に使ってみて見えてきたそれぞれのメリット・デメリットについてわかりやすくまとめてくれました。

みなさまこんにちは  
エンジニアブログ運営委員会の@kakerukaeruです。  
エンジニアブログに登場するのはかなり久しぶりで、サンタ以来になります。ご無沙汰です。

さて、サイバーエージェント公式エンジニアブログですが、2010/08/09の最初の公開から約6年間続けてきて記事総数は300件を結構前に超え、平均すると最初に宣言していた週１の更新を綺麗に守ってきた感じになります。歴史を感じる数値ですね。

 
これもひとえにいつもエンジニアブログを読んでくださっている皆様といつも協力してくれている社内のエンジニアのおかげです。いつもありがとうございます。

ところで、本日は(執筆当時10/13)なんと引っ越しの日だそうで、面白いものですね。必ず毎日何かの日がやってきて、目まぐるしく過ぎていきますね。何でもない日おめでとうがなかなか言えない。

ということで、ココで突然の、  

サイバーエージェント公式エンジニアブログのリニューアル＆お引っ越しのお知らせです！！  

今まで、エンジニア、クリエイター、テクニカルクリエイター、と各領域でブログが別れていたのを統一しCyberAgent Developers Blogへと変貌を遂げます！これからは各領域一丸となって、サイバーエージェントのDeveloperの情報をお届け出来たらと思います！！  

それに伴い、こちらの公式エンジニアブログのprincipiaのページはひとまずの休止活動に入ります。いままで、支えてくださった皆様ありがとうございました。

運営委員会はやめへんで！！！

みなさま、またCyberAgent Developers Blogでお会いいたしましょう！！

それでは！！

どうもこんにちは。技術本部でサーバサイドエンジニアをしている池田 (@yukung) です。約4年振りの投稿になります。こち亀の日暮さんばりの登場頻度でスミマセン。

実は私、今ラスベガスのホテルにてこのエントリを書いています。なぜそんなところに居るのかというと、ラスベガスで開催されている SpringOne Platform (https://springoneplatform.io/) というイベントに参加しているからです。

Image may be NSFW.
Clik here to view.

SpringOne とは

ご存知の方もいらっしゃるとは思いますが一応軽く説明しますと、 Java のデファクトスタンダードなフレームワークである Spring とそのエコシステムをフィーチャーしたイベントで、去年も SpringOne 2GX として開催されました。今年から SpringOne Platform としてリブランドされ、Spring だけでなく、 OSS の PaaS である Cloud Foundry や、マイクロサービス、DevOps、データ分析、マシンラーニングなど、扱う内容が多岐に渡っています。

Image may be NSFW.
Clik here to view.

弊社では昨今、 golang によるマイクロサービスアーキテクチャが花盛りですが、 Java も同じく Spring Boot や Spring Cloud のエコシステムを中心としてマイクロサービスアーキテクチャや Cloud Native への流れがやってきています。そんな中で、海外での技術動向などを肌で感じたいと思い、ここラスベガスまでやってきました。

さて、初日の今日は、開幕前日の様子と、前夜祭のような IGNITE HAPPY HOUR と IGNITE TALKS の様子をレポートしたいと思います。

開幕前日の様子

会場は、ラスベガスの Aria Resort & Casino で行われています。私の宿泊するホテルもここ Aria なので、会場へのアクセスが非常に楽チンで最高です。

Image may be NSFW.
Clik here to view.

宿泊している部屋から

Image may be NSFW.
Clik here to view.

夜景

Image may be NSFW.
Clik here to view.

会場近くに来てみると、展示が行われており、開幕直前の熱気が伝わってくるようです。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

今回は前日でも参加登録が行えたので、早速 register を行います。 register は事前に登録したメールアドレスを会場に用意されているタブレット端末に入力すると、以下のように登録証のイメージが表示されました。

Image may be NSFW.
Clik here to view.

これで Print Away のボタンをタップして登録証の受取エリアに行くと、係の方がその場で登録証を作成してくれました。作成された私の登録証です。ついでにTシャツの交換券と記念ボトルも貰えましたｗ

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

IGNITE HAPPY HOURS

前夜祭ともいうべき、 IGNITE HAPPY HOURS では、入るやいなやお酒や食べ物がバンバン振る舞われ、一瞬でエンジニアの社交場と化しました。私たちも他に日本から来ているエンジニアの方々と情報交換。昨年の SpringOne にも参加された方も居て、去年よりも規模が大きくなっていることなども聞くことができました。

Image may be NSFW.
Clik here to view.

また、アジア系だからか韓国と中国のエンジニアの方からも声をかけられ、滞りつつも英語でなんとかコミュニケーションを図ってみました。中国のエンジニアとは、どんな企業で働いているのか、企業規模や注目しているトピックなどなどをお互いに情報交換をしつつ、彼が注目しているトピックは Spring Cloud と Cloud Native だとのこと。

やはり Spring Cloud を前提とした Cloud Native アーキテクチャは注目度が高いようです。

また、ここで自社のサービスの説明を試みたのですが、上手く説明できず、悔しい思いもしました。私のボキャブラリーの乏しさが根本的な原因ではありますが、日本では一言で通じるキーワードでも、海外では全く通じないことを痛感したりして、グローバルな注目を集めるサービスを持つことの重要さと難しさを改めて知ることになりました。こういう悔しい経験も、海外カンファレンスの醍醐味ですね。

IGNITE TALKS

飲み食いもそこそこに、1時間もすると IGNITE TALKS が始まり、皆が一斉にステージの方へ集まります。IGNITE TALKS (http://www.ignitetalks.io/) とは、日本でも定着している LT と同じように短いプレゼンテーションですが、形式が少し異なり、20枚のスライドを自動的に15秒でスライドさせ、その5分間でプレゼンターが喋るというスタイルのプレゼンテーションになります。個人的には日本ではこのスタイルのプレゼンテーションはまだあまり見たことがない気がしますがどうでしょうか。

トークタイトルの一覧はこちらです。(https://2016.event.springoneplatform.io/schedule/sessions/ignite_springone_platform.html)

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ここでは既に酒も入っていることもあり、終始和やかかつウケ狙いのトークが展開されていました。みながこの場を楽しんでいる、そういう雰囲気が最高でした。

そんな中、日本代表とも言うべき楽天の椎葉さん (@bufferings) が堂々たるプレゼンを全編英語で披露されていました。タイトルは DDD+CQRS on Spring Cloud で、導入からまとめまで話の流れも素晴らしく、スライドも手作り感溢れる手書きスライドを披露し、プレゼン終了後は会場から拍手喝采でした。かっこ良すぎる！

Image may be NSFW.
Clik here to view.

所感

初日の感想としては、とにもかくにもカンファレンスの規模に圧倒されたことと、月並みですがただただ英語力への渇望を掻き立てられました。このエンジニアブログでも、過去記事に海外カンファレンス参加のレポートがいくつかありますが、みな口を揃えて書いているのが英語力の不足です。私も例に漏れず同じ思いをすることになり、初日からモチベーションを揺さぶられる一日でした。明日からはいよいよ開幕です。同行している弊社エンジニアの山田から濃密なレポートをお届けしてくれると思います！お楽しみに！

おまけ

お約束のカジノですが、同行している日本人エンジニアの何人かは何百ドル勝った、という景気のいい話が聞こえてきたりしましたが、私はドル札を溶かしまくるだけという残念な結果だったので、こんなところでお茶を濁したいと思います。

こんにちは。Ameba 統括本部のポイントプラットフォーム事業室でサーバーサイドエンジニアをやっている山田です。
普段はスプラトゥーンというゲームで狙撃手を務めつつ、ドットマネーという Ameba のポイントサービスの保守・開発をしています。

さて、今日も昨日に引き続き、 SpringOne Platform のレポートになります。
このイベントについて詳細を知りたい方は、昨日の記事をご覧ください。

TimeLine

今日のスケジュールはこんな感じ。

Image may be NSFW.
Clik here to view.

朝から晩までみっちり予定が入ってます。

Main Stage

9:00am から Main Stage が始まりました。

Image may be NSFW.
Clik here to view.

広くて薄暗い会場に重低音の効いた心地よい電子音が響き、否が応にも気持ちが高揚しました。

Pivotal の錚々たる方々が、手の込んだ Keynote で会場を湧かせます。技術的な話というよりは開発プロセスやチームビルドの話がメインで、 Cloud Foundry や Spring Boot、 OSS によりもたらされる DevOps や Microservice、 Continuous delivery の恩恵の話が多かったです。

最後は Stephane Nicoll と Josh Long の2人が、 Spring Framework 4.3、 Spring Boot 1.4 の新機能を漫才形式(？)で紹介して笑いをとっていました。

Test ユーティリティが充実したり、 Actuator で Gitコミットが見れたり、 Cache を同期化できたりと、様々な新機能が紹介されましたが、一番盛り上がったのは起動時のログに好きなロゴを表示できる機能だったと思いますｗ

Image may be NSFW.
Clik here to view.

Main Stage は間違いなくこのカンファレンスの一番の見所で、スケールの大きさ、クオリティの高さに終始圧倒されました。

Modern Java Component Design with Spring Framework 4.3

Main Stage 以降は、複数のルームでセッションがあるので、自分で何に参加するかを選択します。

まず Modern Java Component Design with Spring Framework 4.3 に参加。

Spring Framework 4.3 の新機能を Java8 のモダンな書き方で紹介してくれました。見たこともない機能などはなかったので、4.3 の新機能は普通にここで確認すると良いでしょう。

ちなみにこの 4.3 は、 4系で最後のマイナーバージョンになり、2019年までサポートが続くそうです。 4.2 のサポートはまもなく終了。

VerUp の時期を見計らっていた人は頃合いですね。

High Performance Microservices with Ratpack and Spring Boot

High Performance Microservices with Ratpack and Spring Bootに途中参加。

Image may be NSFW.
Clik here to view.

このセッションはソースコードを見ながらの解説がメインでした。

Ratpack とは、 Netty ベースの新しい 軽量な Web アプリケーションフレームワークです。Java8 か Groovy で開発できます。

これと Spring Boot で 高性能な Microservice を、という題材なので、興味を惹かれますよね。

ソースコードは Github に上げてくれているので、ご覧になってみてはいかがでしょうか？

s1p-high-perf-microservices

README.md に EC2 のインスタンス別でベンチマークが載っていますが、ちょっと信じられないような数字です。

Twelve Factor, or Cloud Native Apps

午後は、 Spring Boot と Cloud Native により Twelve Factor App を満たす、という内容のセッションでした。
が、私の英語力と前提知識がなさすぎて、今いち理解ができない部分が多かったため、説明を割愛します。
セッション自体も10分程度で終了し、後は質疑応答、という簡単なものでした。

Testing Spring Boot Applications

最後は Testing Spring Boot Applications

Spring Boot 1.4ではテスト関連の機能がたくさん追加されましたね。

• 新しくなった @SpringBootTest
• RANDOM_PORT で実際に起動した HTTP サーバーのテスト
• @MockBean によるモッキング
• @DataJpaTest による in-memory DB でのテスト
• JSON のアサーション

といった機能の説明と実演をしてくれました。JSON のアサーション、毎回自分でゴリゴリ書くのは辛いので、地味だけど嬉しい機能ですね。

講演後は質疑応答の時間ですが、やはりテストコードは身近な問題なので、盛り上がってディスカッションのようになっていたのが印象的でした。

こちらも GitHub でコードが公開されています。

testing-spring-boot-applications

所感

最後に、海外のカンファレンスに初めて参加した立場から、感じたことを綴ってみます。

意外と忙しい

懇親会などは遅い時間まであり、また朝も早いので、時間の余裕はありません。

時差ボケも相まって、カンファレンス中にウトウトしてしまうこともしばしば。

時間管理をしっかりしないと大変です。

実はこの記事を書いている今も既に 2:30am... orz

会場が寒い

真夏のラスベガスなので、日中の外気温は40℃にも達しますが、会場内は冷房が効きすぎていて寒いです。

事前に参加経験者から忠告を聞いて用心していましたが、想像を超える寒さでした。

しかし現地の人はみんな半袖...

お祭り感がすごい

日本で開催される大きめのカンファレンスと比べても、演出が派手だったり、懇親会が豪華だったり、コミュニティが活性化するための努力が半端じゃないと感じます。お祭り感があってとても楽しいです。

ちなみに食事は朝昼晩すべてカンファレンス側が用意してくれます。贅沢ですね。

夜はお酒も出ます。

写真は、格闘ゲームで他国のエンジニアと交流する池田です。楽しそうですね。

Image may be NSFW.
Clik here to view.

書きたいことが多すぎて、取りとめのないエントリになりましたが、とにかく充実した時間を過ごせています。
エモいことも書きたい気分ですが、最終日も書く予定なので、今日はこのくらいで。

明日は池田の素晴らしい記事がありますので、期待していてくださいね。

秋葉原ラボの高野です。2016/07/29に日本心理学会第80回大会で村瀬美月氏、鈴木麗璽准教授、有田隆也教授（共に名古屋大学大学院情報科学研究科）との共同研究が発表されましたので、それについてご紹介いたします。

ソーシャルゲームでは、多くのヒトが思い思いに自由に行動した結果が詳細に記録されているため、ヒト行動の研究に有用です。これまで私たちはガールフレンド（仮）のデータを用いたヒトの協調行動について研究してきました（以下の関連発表を参照のこと）。本研究ではヒトの協調行動にコミュニケーションのタイプ（1対1、1対多、掲示板）が与える影響について知ることを目的として、そのデータを分析しました。その結果、1対1と1対多のコミュニケーションは協調行動に正の影響を与えることがわかりました。これはコミュニケーションの性質（時間的・心理的なコストなど）によってを効果が異なることを示唆します。また、社会関係の構築・維持におけるコミュニケーションの効果についても分析した結果を報告しました。

発表

• M. Murase, M. Takano, R. Suzuki, and T. Arita, "A statistical analysis of play data in a social network game: Effects of communication on cooperative behavior", 31st International Congress of Psychology (ICP2016), Poster Presentation in Japanese, RC-05-2, 2016.

関連発表

1. M. Takano, K. Wada, and I. Fukuda, "Reciprocal Altruism-based Cooperation in a Social Network Game", New Generation Computing, 34, pp. 257-271, 2016.

2. M. Takano, K. Wada, and I. Fukuda, "How Do Newcomers Blend into a Group?: Study on a Social Network Game", 3rd International Workshop on Data Oriented Constructive Mining and Multi-Agent Simulation (DOCMAS) & 7th International Workshop on Emergent Intelligence on Networked Agents (WEIN) (workshop at WI-IAT 2015), 2015.

3. M. Takano, K. Wada, and I. Fukuda, "Environmentally Driven Migration in a Social Network Game", Scientific Reports, 5, 12481; doi: 10.1038/srep12481 (2015).

4. 高野雅典, 和田計也, 福田一郎, "ソーシャルゲームプレイヤーの協調行動の分析", 人工知能, Vol. 30, No. 1, pp. 74-82, 2015.

参考

• 秋葉原ラボ 発表一覧

どうもこんにちは。先日に引き続き技術本部の池田 (@yukung) です。少し日が空いてしまいましたが、 SpringOne Platform 2日目のレポートをお送りします。

他にもたくさんのセッションがありましたが、今回は私が聴講したセッションを中心にお届けします。セッション一覧はこちらです。

Main Stage

1日目と同様、冒頭は Main Stage という Keynotes セッションでした。
Image may be NSFW.
Clik here to view.

Keynotes 前半

主に前半は Cloud Foundry や OSS, Community の話や、ユーザーである Bloomberg, McKesson, Manulife といった企業がいかにしてソフトウェアを中心にした企業文化に変えていったのかといった culture の話、そして Cloud Foundry と Google, Microsoft, Accenture が協力関係を持ちながらどういった取り組みをしているのか、という話がありました。

個人的には Bloomberg, McKesson といった企業の企業文化の変革のエピソードは興味深く、 Bloomberg は production 環境に1日に 4000 デプロイしていたり、まずプロジェクトに CONTRIBUTE.md を作るようにして、 Pull Request を推奨するようにして社内に OSS のコントリビュート文化を取り入れるように変えていったそうです。 Mckesson は Fortune500 の5位に位置する企業ですが、彼らもまたソフトウェア中心の企業文化を強くアピールしていました。Marc Andreessen の

“ソフトウェアは世界を食う”

という言葉を引用しながら、 Uber, Facebook, Square, Twitter などのように、現在では既存のビジネスをソフトウェア中心の企業が食っていっている、コードはビジネスのために書くのだ、そしてビジネスロジックに集中し、生産性を上げろ、クリエイティビティを上げろ、そのために Spring Boot や Spring Cloud は強い味方となるだろう、という強いメッセージを発していました。"Embrace Software Driven Mindset." とも。

私が聞いていて特に感じたのは、どの企業も技術者だけではなく、ビジネスレイヤーの人たちがソフトウェアや技術に対してビジネスそのものだ、という強い意識を持っていて、ビジネスのスピードを上げるために Cloud Native や Microservices にするんだ、という考えを持って、トップダウンでそういう方向に舵を切っていっていることに驚きました。この辺りは、個人的に日本との違いを感じるところです。

Main Stage 後半

よりテクニカルな話になり、Spring 5 のロードマップや、今後出てくるであろう Java 9 との関係が話されました。 DI コンテナ内部の改善の話や、 Web アプリケーションをより効率的にする仕組みである HTTP2, Reactive Streams ベースのコントローラの導入、Lambda-oriented な HTTP ルーティングや処理の導入など、Spring Framework がより進化していくことを印象づける話でした。JDK9 については、おそらくスケジュールは遅れるものの、 Spring Framework 5.1 で JDK9 をフルサポートするそうです。

その後、 Spring5 の目玉の一つである Reactive Streams 対応についてクローズアップした話がありました。HTTP リクエストを捌くためにスケーラブルにするためのアーキテクチャモデルの変遷（古くは1リクエスト1プロセスの時代から、1リクエスト1スレッド、ロードバランサでの分散処理、そしてクラウド上での水平スケーリングへ）を前提にして、現在ではクラウド上で効率的にリソースを利用して elastic なスケーリングを実現したいはずが、現実はうまく行っていなかったり、コストが掛かってしまっているといった問題があるのではないか、という問題提起がありました。

そこで対応する一つの方法として、クラシックなサーブレットコンテナが提供する様なスレッドモデルではなく、Netty や Node.js でポピュラーとなった少ないスレッド数でも多くの処理が行えるノンブロッキングなランタイムでアプリケーションを開発することで、リソースが節約でき、より効率的にできるのではないかということでした。いわゆる C10K 問題の話ですね。

ただ、ノンブロッキングなプログラミングモデルはコールバックヘルに陥りがちで複雑になりやすいですが、Java8 で登場した java.util.concurrent.CompletionStage を使うことで宣言的に非同期処理を記述できるようになり、さらに java.util.stream.Stream を使うことでコレクションやストリームデータをうまく扱えるようになりました。ただそこに欠けていたのは、Java9 で標準化予定の Reactive Streams の仕様策定にも関わっている Doug Lea が言及した、アクティブになったデータを push スタイルの操作で、そこを補完するのが Reactive Streams である、という説明がありました。

Reactive Streams はとても小さくてシンプルな仕様で、登場するのは Publisher と Subscriber しかおらず、そこに Subscriber からのボリュームコントロールを行う Buckpressure があるだけであるということ、そしてそれらがパイプラインのようにコンポーネント間を繋いでくれるということが説明されました。

Spring5 ではこれを Project Reactor で実現しようとしています。Project Reactor では、Reactive な Data Type として Mono と Flux という型が提供され、 Mono が CompletionStage に当たるもので、Flux は Stream のように複数のストリームデータを扱うためのモデルになります。そしてこの Mono と Flux が、Spring エコシステムの中で複数のマイクロサービス間や分散データストアやメッセージブローカーを介して繋がり、全てがデータのストリームで表現できるようになる、というのが Spring5 で実現しようとしている世界である、というメッセージでした。

では具体的に Spring5 でどの辺りが変わるのかについては、以下の図がわかりやすいと思います。

Image may be NSFW.
Clik here to view.

Spring MVC での Controller のリクエストハンドラで、Reactive Type である Mono, Flux が引数や戻り値で扱えるようになる Spring Web Reactive が新しく提供されます。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

これはまた RxJava とも互換性があります。

Image may be NSFW.
Clik here to view.

REST API から別のエンドポイントを叩く例では以下のように記述することができます。

Image may be NSFW.
Clik here to view.

また、それに伴って、HTTP リクエスト／レスポンスの読み書きに Reactive な HTTP API が使われるようになり、InputStream/OutputStream が Flux や DataBuffer などで表現され、HTTP ソケットとのやりとりが Backpressure 付きで扱えるようになります。

そして、それらの基盤となるサーブレットコンテナでは、ノンブロッキング I/O が利用可能になった Servlet 3.1 Container の Tomcat/Jetty だけでなく、Java でノンブロッキング I/O の先駆けであり、サーブレットコンテナではないランタイムである Netty や、同じくノンブロッキング I/O をサポートするWebコンテナの Undertow が Spring5 でサポートされます。

最後に、Reactive Streams 対応がその他の Spring プロダクトにどういう効果をもたらすかに触れ、例で上がっていたのは Spring Cloud Stream というマイクロサービス間のメッセージングを実現するフレームワークでも、Reactive な Type で input/output を扱うことで、同様に Reactive なプログラミングモデルで記述することができるとのことでした。

Image may be NSFW.
Clik here to view.

後半の Technical Keynote は、Spring エコシステムがどういう方向に向かっているかということを知ることで、自ずと Reactive Streams や Microservices、分散メッセージング等の技術がどう繋がっていくのかが想像できる話で、個人的にとても得るものが多かったです。この辺りについて詳しくは

• https://spring.io/blog/2016/04/19/understanding-reactive-types

に記載されています。また日本語の資料としては @making さんの JJUG CCC 2015  Fall の資料がとても理解しやすいです。

Putting a SpEL on Spinnaker: Evolving an Expression Language for Continuous Delivery at Netflix

• Session Abstraction

Spring Framework で利用できる式言語である SpEL(Spring Expression Language) を、Netflix OSS でも有名な Spinnaker で、パイプライン記述言語としてどのように使っているか、というセッションでした。 SpEL は他にはテンプレートエンジンの Thymeleaf でも使えることで知られていると思います。

Spinnaker は、マルチクラウド対応のインフラ・アプリのデプロイとクラスタ管理を実現し、継続的デリバリを自動化するソフトウェアです。Netflix は AWS のデプロイ・継続的デリバリの実現に Asgard という OSS を提供していましたが、その後継となるものです。

Spinnaker では、デプロイパイプラインを定義する際のステップの条件記述や、デプロイ単位のスタックの指定に SpEL で指定することができ、柔軟な記述が動的にできるとのことでした。動的に記述できることで記述量が減らせるので、パイプラインの定義がより気楽に行える、ということでしょうか。

また、セッション中のデモではインフラのデリバリを Jenkins のビルドパイプラインで構成して、AMI を指定して SpEL で記述されたコンフィグパラメータをインジェクションして、インスタンスの生成、テスト、Production への投入を自動化する例を実演していました。さらに SpEL の便利な使い方として、 Spinnaker では #alphanumerical や #fromUrl、#stage などのヘルパー関数を提供して、より簡単にかつパラメータチェックなども行えるようにしている、と言っていました。また、デモの中で、先日 Netflix からリリースされたマイクロサービスを可視化する Vizceral のデモをしていましたが、個人的にはこっちの方に興味を引かれてしまいましたｗ

• https://twitter.com/yukung/status/760911953120272384

Spinnaker の Pipeline Expressions のドキュメントはこちらにあるので、興味がある方はどうぞ見てみてください。

Architecting for Cloud Native Data: Data Microservices Done Right Using Spring Cloud

• Session Abstraction

Data Microservices というデータに着目したマイクロサービスアーキテクチャを、Spring Cloud Data Flow と Spring Cloud Stream を使って実現するというセッションでした。

Data Microservices は、このセッションだけでなく他のセッションでも頻繁に聞かれたキーワードでしたが、このセッションで Data Microservices とはどんなものかイメージすることができました。マイクロサービスアーキテクチャと聞いてよくイメージされる、モノリシックなアプリケーションを分割したシステム的なアーキテクチャのコンセプトを、データ処理のプロセスも同じように適用します。モノリシックな1枚岩のデータ処理プロセスではなく、小さいプロセスを組み合わせることで、データを加工するプロセスをより迅速に開発し、リアルタイムにユーザに分析結果をフィードバックできるように、というのが Data Microservices のコンセプトだと思います。

コンウェイの法則で語られるように組織ごとにマイクロサービス化が進んでいっても、連携するシステムは相変わらずモノリシックだったり巨大なシステムが残り、それらを Integration Bus や ESB(Enterprise Service Bus) などで繋ぎ、ETL ミドルウェアで集約しデータ・ウェアハウスなどに蓄積するのが典型的なデータ分析のアーキテクチャですが、これは高価なソリューションであることが多く、また、夜間バッチなどで頑張って計算を行っているのが実情で、夜間バッチが遅れたりすれば分析業務にも影響が出ますし、リアルタイムな分析や機械学習は難しいという問題があります。

Image may be NSFW.
Clik here to view.

そこで Data Microservices では、モノリシックなデータ処理プロセスの一つ一つを分解し、それぞれをマイクロサービス化することで、迅速なデプロイや Blue-Green デプロイメントを可能にし、デリバリ速度を上げる事でデータ分析の精度を上げることができるということでした。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

具体的には、一つ一つのデータ処理プロセスは Spring Boot のプロセスでマイクロサービス化し、それぞれのプロセス間や、メッセージキューなどの各種ミドルウェアとのメッセージングを Spring Cloud Stream で簡単に統合することができるそうです。

Image may be NSFW.
Clik here to view.

そしてこれらをクラウド上で実現することで、メトリクスやモニタリング、ログの集約やオートスケーリング、自動回復なども実現できるとも付け加えていました。また、データ処理パイプラインを Spring Cloud Data Flow を使って定義することで、それぞれのデータ処理プロセスをオーケストレーションすることができるようです。

Image may be NSFW.
Clik here to view.

ここまで説明したところで、デモとしてリアルタイムに入ってくる POS データを元にして機械学習を通して決済結果のリスク分析を行い、結果をリアルタイムにブラウザに出力するデモを披露していました。

デモ風景

Image may be NSFW.
Clik here to view.

デモのアーキテクチャ

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

こうした Spring Cloud Stream/Spring Cloud Data Flow を使ったアーキテクチャの全体像がこちらで、Business Microservices と Data Microservices とに分けられているのが特徴的です。

Image may be NSFW.
Clik here to view.

個人的にこの図を見た時に、Main Stage で紹介されていた Spring5 の Reactive Streams が目指す全てをストリームで扱える、という世界が具体的なイメージとして自分の頭の中に入ってきた感じがしました。

今回のデモはソースコードが GitHub にありますので、興味があれば是非読んでみてください。

Wall St. Derivative Risk Solutions Using Geode

• Session Abstraction

ウォール街のデリバティブ取引のリスク分析に Apache Geode を使っている事例のセッションでした。が、ちょっと専門用語が多く、またスピーカーの喋り方がくぐもった声で聞き取りづらかったことで、あまり理解することができませんでした。。。そのうちセッションの動画が公開されると思うので、その際にまた見なおしてみたいと思います。Apache Geode 自体は、インメモリデータグリッドのソフトウェアで高速＆スケーラブルである、ということくらいしかまだ知識がなかったのですが、セッション中で相当量のトランザクションを捌いている話をしていたと思うので、今後自分でも触ってみたいと思っています。

Cloud Native Streaming and Event-Driven Microservices

• Session Abstraction

マイクロサービス間のメッセージングを行うフレームワークとしての Spring Cloud Stream の紹介と、その中身や仕組みについてコードやデモを交えて説明されていたセッションでした。上記で紹介した Data Microservices のセッションを見て、マイクロサービス間のメッセージングについてより興味が出てきていたため、Spring Cloud Stream の理解を深めるのにちょうどよいセッションでした。資料が公開されていましたので貼っておきます。

基本的には、Spring お得意のアノテーションを使って、メッセージの input/output を簡単に指定でき、具体的なメッセージングミドルウェアの実装も binder という概念で扱えるため、様々なメッセージングミドルウェアを透過的に扱える、という感じでしょうか。Spring Boot が基盤となっているため、アプリケーションを作るのも楽ちんなのが良いですね。

現在 Production Ready なミドルウェアとして、Apache Kafka や Rabbit MQ がサポートされており、Experimental ではありますが JMS や Google PubSub もサポートされているようです。他にも consumer ごとのグルーピングやパーティショニングなどもできるようです。セッションの最後に、Spring Cloud Stream 1.1 でサポートされる機能や、様々なデータソースのスキーマをバージョン管理する schema evolution の紹介や、将来的な展望も紹介されていました。

マイクロサービス化を進めていくと、この辺のメッセージングの仕組みも必要になってくると思うので、Spring Boot 同様、基盤となるソフトウェアになっていくかもしれないので、今後キャッチアップしていきたいですね。

Transforming the Monolith at 20M tph

• Session Abstraction

2日目最後は、Comcast というケーブルテレビ・インターネットプロバイダの事業を行っている企業のマイクロサービス化の事例セッションを聴講しました。

内容としては、よく日本でも聞くような話でした。2億5000万/日の大規模トランザクションでかつ500台以上のサーバを抱える中で、以下の様な問題に直面したそうです。

• レガシーなコードベース
• 人手での手動オペレーション
• 物理インフラ
• ぐちゃぐちゃに混じりあったデータ
• 開発速度が出ない

これだけでもどこかで聞いた話だなぁと思うわけですがｗ そんな中、Comcast は一つは文化的な側面、もう一つは技術的な側面という2つのアプローチで組織を変革していったそうです。

文化的な側面では、Dev, Ops, QA それぞれの間にあった壁を壊すために、一つのチームにそれぞれの役割を含むように変え、自己組織化を促していったそうです。

技術的な側面では、マイクロサービス化を進めていくとともに、データの責務を分けて整理したこと、そしてテクノロジースタックも

• Weblogic -> CloudFoundry
• Oracle -> Couchbase
• IPベースのルーティング -> Consumer ベースのルーティング

に変えていき、CI やデプロイも

• Jenkins -> GoCD
• Maven -> Gradle
• 自作スクリプト -> Continous Delivery

というモダンなものに変えていったそうです。

そうした変化が、現在では CloudFoundry 上でゼロダウンタイムデプロイを実現するプラグインや Canary デプロイメントを実現するプラグインを開発して OSS で公開するまでになったそうで、そうした成果は GitHub で公開されています。将来的には外部サービスの影響をさらに縮小し、より多くのサービスを CloudFoundry 上に持って行きたいとのことで、これからさらにマイクロサービス化を進めていくことが印象的でした。

個人的な印象として、アメリカでは AWS や Netflix の事例がよく挙げられるために企業のマイクロサービス化が大分進んでいるのだろうという思い込みがあったのですが、このセッションの他にもいくつかセッションを聞いていく中で、アメリカでもまだまだこれからマイクロサービス化しようとしている、もしくは現在進めている、という企業が多いことを知りました。こういう感覚を現地で知ることができたことも、今回来て良かったなぁと思うところでした。

2日目の感想

全体を通して、 Microservices と Reactive Streams、Data streaming, Messaging などが強調されたセッションが多かったと思います。そしてそれらをサポートするミドルウェアとしての Kafka や Geode, 統合するフレームワークとしての Spring Cloud が今後より進化していくことが印象的でした。これらの技術要素が結びついていくことが実感として感じられたことが、今日の大きな収穫です。

ただ大分広範囲に渡って色々出てきたので、日本に帰ってからキャッチアップするものがたくさんあって大変だなぁというｗ あと結構2日目も一日セッションだったので大分疲れました。部屋に戻ってから寝オチしていたのは内緒です。

明日は最終日ですが、まだまだ興味深いセッションが多いので明日も頑張ってレポートしたいと思います！

サイバーエージェント公式エンジニアブログをご覧の皆さんこんばんは、技術本部サービスリライアビリティグループの須藤(@strsk)です。最近2016年で3回目の役満、大三元を和がりました。

Image may be NSFW.
Clik here to view.

本日は、9月6日に行われたGCP NEXT World Tour Tokyoにて発表した資料を公開します。

技術本部 Advanced Dev.Center（略してADC）の村上です。

私達はMake Your Goals Come True. Easier + Faster. 

をコンセプトに開発環境の改善や統一化を行ってます。

タイトルのとおり、私達の組織ではソースコードのバージョン管理システムとしてGithub Enterprise（以下GHE）を導入しており、今回久しぶりにアップデートを行ったので、それについて書かせていただきます。

なお、今回の作業にはADCメンバーに加え、敏腕インフラエンジニアの@kakerukaeruさんのお力添えあってこそということを彼の上司@strskへ向けてアピールしておきます。

規模・SPEC

規模感としてはユーザ数は約1000名、Organization約400、Repository約10,000になります。

- Primary on AWS EC2

Instance Type :r3.4xlarge

EBS(root device) :100GiB

EBS(block device) :1500GiB

- Replica on AWS EC2

Instance Type :r3.4xlarge

EBS(root device) :60GiB

EBS(block device) :1500GiB

アップデート方針決め

アップデート前のバージョンはVersion 2.2.7で、アップデート検討中にVersion2.7が発表されたのですが、発表されたばかりだったため2.7系へのアップデートは行わず、2.6系に留めることにしました。

今回Version 2.6.8にアップデートしたわけですが、GHEの仕様上、アップデートは現在のバージョン(v2.2.7)から最新バージョン(v2.6.8)まで一気に行うことはできないので、いったん2.4系へアップデートしてから2.6系へアップデートする手順を踏んでいます。

今回の作業で最も注意を払った点は

・会社の資産であるソースコードや付随データを失わないこと

・サービスに支障をきたさないこと

なので万が一のことを考えいつでも戻せるような手順を事前検証を行いつつ、何度も考えては議論しました。

Image may be NSFW.
Clik here to view.結論

・アップデート前のプライマリはアップデート後もそのまま残しておいて、いつでも元のバージョンへ戻せるようにしておく。

・アップデートするのはレプリカのみとする。アップデート後は本番のElasticIPを付け替えて本番として利用する。

・新プライマリ、旧プライマリのそれぞれには新規でレプリカを用意する。

Image may be NSFW.
Clik here to view.

事前検証＆準備

主に検証したのは以下になります。

・インスタンス作成〜レプリケーション

・リストア検証、snapshotからの再構築
今回は切り戻しをしないので本手順は発生しませんが、再現性の確認のため実施。

・プライマリとレプリカの設定ファイルの比較

$ ssh -p122 admin@hostname -- 'ghe-config -l'

でCLIから設定の確認ができます。

アップデート前はv2.2だったのでレプリカとの設定ファイルの結構差分がありました。

・backupUtilsの更新

githubの公式ツールであるbackupUtilsが古くなっていたので更新。

・EBS snapshotの作成

snapshotは差分バックアップなので、事前に実行しておくとメンテナンス時間中のバックアップが短くてすみます。

手順

・メンテナンス開始告知

・メンテナンスモードに入れ、ユーザアクセス遮断

・バックアップ（ backup-utiles及び EBSスナップショット）を取得

・レプリカとプライマリのレプリケーションを切断

・レプリカのSettingsをプライマリと同じにする

・レプリカをアップデート（v2.2.7 -> 2.4.9 -> 2.6.8)

2.2.7 -> 2.4.9は約1時間、2.4.9 -> 2.6.8は約40分かかりました。

・新しくレプリカ機を用意しレプリケーション開始

・プライマリとレプリカのElasticIPを付け替える

この作業により、DNS更新なしにレプリカを本番に置き換えることができますし、万が一の場合も即時元のバージョンへ戻すことができます。

・メンテナンスモードを解除

確認コマンド

アップデート前後でのrepoやorganizationデータの比較に利用したAdmin用APIは下記になります。

- Repository listhttp(s)://<hostname>/stafftools/reports/all_repositories.csv- Organizations listhttp(s)://<hostname>/stafftools/reports/all_organizations.csv- Gist list（only public）http(s)://<hostname>/api/v3/gists/public- number of issue, hook, milestone, orgs, repost, comment etchttp(s)://<hostname>/api/v3/enterprise/stats/all

アップデート後

1. pull requestが消えた!?

メンテナンス終了後、業務開始時間になると、pull requestが表示されないとの報告が続々と寄せられました。

アップデート前後のpull request数の変化はなく、詳細に確認してみるとlistの表示だけに問題があることがわかりました。結果としてindex作成が終わっていないことが原因でした。その後もindex作成は完了せず、結局、16時間後に確認した時点で80%弱の進捗でした。

翌朝ようやくIndex再構築の完了が確認でき、pull requestのリスト表示は正常に戻りました。次回のアップデートでは事前に周知しておきたいです。

2. deploy keyが消えた!?

GHEの仕様でdeploy keyはrepository毎に設定してくださいというアナウンスをしていましたが、事実上2.2系では同じorganization内であればdeploy keyの使い回しができてしまっていました。v2.4にバージョンアップしたことで仕様に忠実(？)になり、その使い回しができなくなったようです。

https://enterprise.github.com/releases/2.4.0/notes

正しい挙動になったということなのですが、一部利用者間で混乱が発生する事態になりました。repository数が多いプロジェクト救済のため、MachineUserの運用も検討しましたが、複数のデメリットが払拭できず見送ることにしました。
GHEへMachineUserの運用について問い合わせたところ、issueは上がっているものの、現行、一般ユーザと権限・コスト両面で同様の取り扱いということでしたので、改善を待ちたいです。

3. markdownの画像が表示されない!?

バージョン2.6からW3Cのレコメンドに従い、HTTPSコンテンツ上のHTTPコンテンツ（いわゆるmixed content）はブロックするように仕様変更されていました。

なので2.6以降使えなくなっています。

https://enterprise.github.com/releases/2.6.0/notes

4. やっぱり古いバージョンを残しておいて良かった

こちらは頃合いをみて削除予定ですが、アップデート後はたくさんの方が検証するために、アップデートとは無関係の事象も報告されたりするので、問題の切り分けのためにも残しておいてよかったと思いました。また、いざという時はこっちにそのままのデータがあるという安心感も大きいです。

これから

未解決の問題もまだ残っており、新機能の検証、バイナリデータの管理等改善したい項目が日々生まれている状況です。全サービスのエンジニアと協力し合いながら、快適な開発環境の提供をチームで取り組んでいきます。

いつもADCに協力してくれるエンジニア・クリエイターの皆様、いつもありがとうございます。皆様の激励が我々の励みになっています。

また今回の記事が同じような開発環境を担当している方々の参考になれば幸いです。
 

こんにちは
株式会社AbemaTVのAbemaTV FRESH!でフロントエンドの開発をしているすちをと申します。

今回は9月にオランダのアムステルダムで開催されたIBC2016（International Broadcast Conference）に参加してきましたのでその報告をさせていただきます。

IBCとは

もともとはヨーロッパ内の放送局向けに、放送分野を中心とした映像・音響技術の展示会として開催されはじめたイベントですが、近年ではそれに加えインターネット配信に纏わる幅広い最新テクノロジーのアピール場所となっています。今年は世界各国から1,600を超える出展がありました。

会場

Image may be NSFW.
Clik here to view.

毎年RAI(東京でいうビックサイト・大阪でいうインデックス)という会場で開催されています。

Image may be NSFW.
Clik here to view.

会場内はジャンルごとに14のセクションへと分かれていています。

中央にある3のホールでは期間中講演が行われていました。

ご覧の通り広大で、何回も迷子になってしまいました。

Image may be NSFW.
Clik here to view.

ゲート付近の端末で事前に予約しておいたメール内のQRコードを読み取ると、プリンターから入場カードが印刷されます。

ブース

今回見たブースの中で特に気になったものを紹介していきます。

IBM

Image may be NSFW.
Clik here to view.Martin Runde@emrunde 

#IBM zeigt #cloud video Lösungen auf der #IBC2016 in Amsterdam #ibmcloudde https://t.co/t0EcCT1N4f

2016年09月12日 22:33

ブースの写真を撮り忘れたので拝借させていただきました。

Image may be NSFW.
Clik here to view.

IBMが開発している自然言語処理のWatsonを用いて、テニスのUSオープン映像に含まれている音声を字幕におこすデモが展示されていました。

サンプルをみていただくとわかると思いますが、Confidenceは70〜90%台とほぼ正確に字幕として表示されています。

実際にBluemixから使用が可能となっており、日本語にも対応している所が驚きでした。

Adobe

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Adobe CCに搭載される新機能の発表と共にデモが行われていました。

私が聞いた内容としてはAbode Premiereで

• チームプロジェクト機能が強化される
• ファイルはローカルではなくクラウド上で管理される
• アプリケーション内でチャットのように共有作業者を招待できる

というものでした。

これまでは1人の作業データをクラウドで扱うという感じでしたが、これからは複数人がクラウド上で同時に作業を行えるというAdobeのアナウンスでした。

詳しくはコチラにまとめられていたので気になる方は見てみて下さい。

Crevo

Image may be NSFW.
Clik here to view.

FRESH!の配信でも使用されているLiveShellは配信時に映像リソース(カメラなど)からHDMI経由でLiveShell端末を繋ぐことによってそのまま配信サーバーに映像を飛ばす事ができるデバイスです。(=PCを使わずに配信できるのがメリット)

こちらで新しく展示してあったLiveShell.Xは1080p/60fpsでの生配信が可能なものなので将来的にはFRESH!でもこのレベルの画質で遅延なく配信できればいいなと感じました。

Image may be NSFW.
Clik here to view.Engadget Japanese@engadgetjp 

一般向けモデルとしては最高クラスの機種です。 / Cerevoのライブ配信機材「LiveShell.X」はプロの現場でどこまで使えるのか？ 岩佐社長のインタビュー動画付き - Engadget Japanese https://t.co/7krbISpM36

2016年09月17日 05:33

Peer5 Happy Our

Image may be NSFW.
Clik here to view.

夕方からは徐々に各ブースで🍺や🍷が配られるようになり参加者やブースの出展者が交流を深める時間となります。

私もHls.jsの作者である@manguiさんとお話をしました。(Peer5のブースでした)

FRESH!では数ヶ月前から一部のブラウザでHls.jsを使用しており、manguiさんが「最近TwitterでHls.jsと検索するとよく日本語のツイートでAbemaと引っかかるようになったがお前のとこか」の様なことを言っていましたw

各国のエンジニアたちもクロスブラウザでのHLS(HTTP Live Streaming)再生に疲弊しているようで、デンマークから来たエンジニアはその場で1時間くらいmanguiさんにWebVTTの質問をしていました。

所感

知らないことが多かった

今回このIBCに参加して心に残ったことは自分の知らない発見がたくさんあったことでした。映像という分野において4K、HDR、VRなどの技術をどうWebの中で表現していくか注視していきたいと思います。またOTTの台頭によってインターネット動画の機運が世界的に急速に高まっていることも身にしみて感じました。Image may be NSFW.
Clik here to view.

つたない英語でも親身に受け答えしてもらえた

IBCに参加されている方は皆さん優しく、私みたいな英語スキルの低い日本人の質問にも耳を傾けてくださいました。それ故、今回来ていたヨーロッパ各国のエンジニアと同じくらいスムーズに議論できるようにならないとと痛感しました。

Image may be NSFW.
Clik here to view.

アムステルダムはすごいいいところだった

コンパクトな街で市内であれば自転車やロードバイクでアクセスできそうな感じでした。Heinekenがものすごく安くかったです。

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

技術本部 Advanced Dev.Center（略してADC）の大倉です。

私達は、Make Your Goals Come True. Easier + Faster. 、をコンセプトに1600人規模の開発環境の改善や統一化を行ってます。

この記事は、CircleCI Enterprise管理者を対象としております。今後、導入を予定されている管理者の方にとって、少しでも有益な情報になればと思います。

CircleCI kim様、kevin様、いつも迅速なサポートありがとうございます。とても感謝しております。

CircleCI kim, kevin

Thank you very much always for your cooperation !

なぜ、オンプレ化したか

当初のEnterprise版は.com版と同じようにクラウドサービスとして展開されていましたが、2016年にCircleCI Enterpriseのビジネスモデルに更新が入ったことで、

たとえば、継続してクラウドサービスとして利用する場合、

• 高額（前年度比較７倍弱）の更新費用がかかる
• iOS用のビルド・テスト環境が利用できない

という状況になったことが主な理由です。

オンプレ化のメリット／デメリット

• メリット

次章”アーキテクチャ詳細図”のようなサーバー構成にしたところ、ビルド及びテスト処理速度が速くなりました。つまり、サーバー構成をカスタマイズできる点が

大きなメリットでしょうか。また、ビルドイメージをサービス仕様に合わせてカスタマイズすることもできるので、より処理速度を速くできるという点もあります。

• デメリット

サーバー構成やビルドイメージをカスタマイズできるメリットの代わりに、それを運用・管理する困難さが管理者に発生します。Enterprise版は発展途上なので、管理者向けのドキュメントやノウハウは、利用者向けのドキュメントと比較するとかなり少ない状況ですので、CircleCIのエンジニアと情報共有をしながら、BugFixしてもらいながら、運用・管理する必要があります。

アーキテクチャ詳細図

Image may be NSFW.
Clik here to view.

基本、GithubEnterpriseへのPush→（トリガー）→CircleCIEntrepriseでJobを実行 → 結果をSlackへ送信
といったCI環境を構成しています。CircleCIEntrepriseはymlの設定だけでCI環境を得ることができるため、プロジェクト毎にサーバを用意することなく、属人的作業も排除することが出来、サービス品質を維持していく上で重要な役割を担っています。

"Immutable Infrastructure"という設計

BuilderBoxは基本使い捨てする設計（Immutable Infrastructure）で提供されているのですが、弊社のOn-Premise（OpenStack）環境では、インスタンスを使い捨てるような設計にすることが厳しかったので、LXCコンテナデータを削除し、コンテナイメージを再ダウンロードすることで、LXCコンテナを使い捨てる（初期化する）ことにしました。

$vi /etc/init/circle-image.conf---> 9行目のmanualをコメントアウト#manual<---$ sudo service circle-image start$ sudo tail -f /var/log/upstart/circle-image.log〜省略〜+ curl -sSL -o /mnt/tmp/container.tar.gz https://circleci-enterprise-assets-us-east-1.s3.amazonaws.com/containers/circleci-precise-container_0.0.1338.tar.gz+ untar_image /mnt/slave-image+ SUBVOLUME=/mnt/slave-image+ sudo -n btrfs subvolume create /mnt/slave-imageCreate subvolume '/mnt/slave-image'+ sudo -n tar -xp --use-compress-program=pigz -f /mnt/tmp/container.tar.gz -C /mnt/slave-image --numeric-owner

監視（CLITICAL）

主に監視をしているのは以下の項目です。

• ServiceBox（cpu, disk, url（https://{circleci-url}) , load , ntp, docker containers）
• BuilderBox（“Fleet State = not-healthy”, “queue total wait time per instance" and "leaked error at a container”）

監視をする上で利用しているREST APIは、この辺でしょうか。

※非公式APIも含まれますのでUpdateにより利用できなくなる可能性があります。

• https://{CIRCLECI URL}/api/v1/admin/build-state-summary
• https://{CIRCLECI URL}//api/v1/admin/build-state
• https://{CIRCLECI URL}//api/v1/admin/recent-builds?shallow=true&offset=0&limit=100
• https://{CIRCLECI URL}//api/v1/admin/users?circle-token={TOKEN_CODE}
• https://{CIRCLECI URL}//api/v1/admin/recent-builds

スケールアウト

（アーティファクトを保存する先としては、AWS S3を利用してるため）スケールアウトはBuilderBoxのみ考えれば問題ありません。

free / busy コンテナの数をグラフ化し、以下のようにグラフが交差したときに弊社では2インスタンス（6コンテナ）追加しました。

Image may be NSFW.
Clik here to view.

コンテナ

コンテナは、Javaプラットフォーム上にClojureで作られているようです。

$ lein repl :connect 6005

で対話式に設定変更が可能ですが、通常アクセスする必要はありません。

（弊社ではDebugするためにCircleCI様の元でアクセスすることはありましたが）

なお、Javaプロセスは、以下のように起動しています。

sudo -E -u ubuntu java -Djava.net.preferIPv4Stack=true -server -XX:+UseConcMarkSweepGC -Xss1m -Xmx4g -Xverify:none -XX:+CMSClassUnloadingEnabled -Dfile.encoding=UTF-8 -jar /var/cache/circle-builder/circle.jar

はまったところ

ステージング環境ではまったのですが、NTPの時刻がServiceBoxとBuilderBoxで合ってないとServiceBoxにてBuilderBoxが正常に認識されないということがありました。

ステージング環境でも最低限の監視は入れたほうがいいですね。

おわりに

CircleCIでは、.comの運用をAWSで行っているからかAWSを基本とした設計になっています。予算に余裕があれば、オンプレ化するなら、AWSをおすすめします。

また、発展途上のツールなので、最新のバージョンにしておいたほうがBugを踏まなくて済みます。

参考URL

• https://circleci.com/docs/enterprise/

• https://enterprise-docs.circleci.com/

こんにちは。サイバーエージェント17卒内定者で現在アメーバブログでアルバイトをさせていただいている柳耕太です。
少し日は空いてしまいましたが先日行われたHTML5 CONFERENCE 2016のレポートを書かせて頂きました。

基調講演

基調講演前半

基調講演は前後半に別れており、前半は慶應義塾大学環境情報学部教授でW3Cサイトマネージャーでもある中村 修教授が登壇しました。

中村教授はWEBというものが世の中に現存する媒体（雑誌、カタログ、ニュース)を表現するものにとどまるのではなく、新しいデバイスやデータの扱い方等をハンドリングしてユーザーに提供しなければならない。といった今後進化する技術にWEBが対応すべきであるという話、そして最近よく聞かれる IoT, ビックデータ, 人工知能等 という技術はWEBという基盤の上に成り立っているものであり、地球を取り巻く大規模なOSと化しているWEBが抱えている問題を解消するために行われている活動や作業についてのお話をしていました。
 

ものすごくスケールの大きな話で、自分も含めホールでお話を聞いていた全員がWEBが社会でも重要な役割を占めていることを再認識していました。

[動画]

基調講演後半

後半にはGoogleでChrome開発に携わった経験を持つIncrements株式会社の及川卓也さんが登壇しました。

及川さんは アプリケーションとしてのWEB, メディアとしてのWEB, 基盤技術としてのWEB, といった3つの側面から見たWEBについて以下のことをお話していました。

1. 紙としてのメディアを超えたコンテンツにするためのAPIが増えてきている
2. 現代人はスキマ時間でスマホをいじるようになりニュースキュレーションサイト等の利用が増えているが、WEBには純粋なコンテンツ意外のリソースや外部リソースなどが多いのでアプリに流れがちといった今のWEBの問題点
3. WEBがこれからも重要であり続けるために、一旦立ち戻って「WEBに再投資すること」さらには「WEBを再発明すること」で正しい技術の発展の仕方を考えるべきである

そして、WEB広告の問題点を解消するためにAMPというものがあるが、CMSやツールなどが対応を阻害し対応したくても対応出来ない会社も多いというWEBの進化を阻害する要素についてもお話してくれました。

WEBの光と影をわかりやすく説明していただけたので、今現在どういうことが問題になっていて、どういう対策が講じられているのかがよく分かるお話でした。

[動画]

Reactの最新動向とベストプラクティス（株式会社TOLOT:小林 徹）

近年良く耳にするFacebook制製のJSライブラリ「React」がどういったプロダクトに使われているのか、Reactの歴史、Reactの特徴などを話した後、開発をサポートするツールについてやアップデートの際、破壊的な変更は無く非推奨のメソッドなどは1つ前のメジャーバージョンで警告をしてから廃止される。といったReactを実際のプロジェクトに組み込む際に気になる部分についても触れてくれました。

そして、今後はDOMの差分の検出・適応が同期的に行われているものを、優先度の高い処理と低い処理のレンダリング方法を変えるためにアルゴリズムの全面書き換えが行われていると言ったこれからのReactについてもお話してくれました。

React.PureComponentがshouldComponentUpdateの書き間違えによる、データは更新されてるのに再レンダリングされないという罠にハマるのを解消してくれそうな存在だと感じました。（良くハマるのは自分だけでしょうか）

資料

HTML5/JSモバイルアプリ最前線 (アシアル:田中 正裕)

Stack Overflowが行っている普段どういう言語を使っているかという調査によると、JavaScriptは総合1位、フロントエンド開発1位、バックエンド開発1位となっているが、モバイル開発ではJSは全然人気では無いというお話をした後、JSでモバイル開発を行うためのソリューションの歴史のお話をしてくれました、その中でも Cordova, ReactNativeについて深掘りして話してくれました。

Cordovaはすでに太いレールが敷かれているが、新しさは無く動きは活発ではなく、React Nativeはみんながバラバラにレールを引いているが、刺激的で動きが活発であるというのが所感だそうです。

そして、Googleが提唱するProgressive Web Appsという開発パターンの特徴についてお話した後三者の比較をしてくれました。

[比較画像]
Image may be NSFW.
Clik here to view.

それぞれの技術について色々な側面からのお話が聞けて、JSモバイルアプリ開発を行う際、技術選定に困ったときに参考になるお話でした。

資料

Material Design を使ったマルチデバイスに対応するデザインの作り方（Google:鈴木 拓生）

現在、様々なデバイスでWEBページを表示できるが、デバイスによって見た目がバラバラでユーザー体験が統一化されていないのを解決するために「Material Design」というデザインフレームワークが誕生したというお話の後、Device metrics, Resizer, といったMaterial Designの考えを組み込んだレイアウトを考えるためのツールや Google Fonts, Noto Fonts, Material Icons, といったフォントやアイコンなども紹介してくれました。

そして、フレームワークを使うことをゴールとするのではなく、フレームワークを使った上で何をするかが大事である。とデザインフレームワークに縛られるのも良くないと話を締めくくりました。

今回のお話はこちらに書いてあることを抜粋したものだそうです。

用意されたUIを使うことでどうUXを向上させるかという部分に集中して考えることができるので、このようなデザインフレームワークがあるとものすごく助かります。

お話の中にもありましたが、デザインフレームワークに縛られるのではなくそれを使って何ができるのかを今後考えていきたいと思いました。

TechFeedのつくり方 - Angular2 / Webpack / Ionic2 / Cordova実践入門（株式会社オープンウェブ・テクノロジー:白石 俊平)

今後Webはコンポーネント指向になる!という断言からスライドが始まり、TechFeedというサービスを作るために何故 Cordova, Angular2, Ionic2, Webpack, といった技術を選定したかというお話をした後、どういう開発フローで開発が行われているのかというお話をしていました。この開発のメリットとしては、Web, iOS, Androidのコードが統一できるため１人のエンジニアが横断的に様々なデバイスに携われることですが、１人のエンジニアが全デバイスの面倒を見なければならなくなるというデメリットもあるというお話もしてくれました。

そして、今回開発に使用した Cordova, Angular2, Ionic2, Webpack, について実際に開発に使ってみて見えてきたそれぞれのメリット・デメリットについてわかりやすくまとめてくれました。