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

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

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

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

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

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

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

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

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

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

それでは！！

こんにちは。サイバーエージェント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という開発パターンの特徴についてお話した後三者の比較をしてくれました。

[比較画像]

それぞれの技術について色々な側面からのお話が聞けて、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, について実際に開発に使ってみて見えてきたそれぞれのメリット・デメリットについてわかりやすくまとめてくれました。

技術本部 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してもらいながら、運用・管理する必要があります。

アーキテクチャ詳細図

基本、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-image
Create 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コンテナ）追加しました。

コンテナ

コンテナは、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/