はてなブックマーク

はじめに こんにちは。次世代システム研究室のT.Tです。 以前の記事でAnsibleのベストプラクティスへの橋渡しとなる基本的な構成についてご紹介しました。 今回はローカル環境から本番環境まで通して適用できるplaybookの構成例について、ベストプラクティスに加えて効果的なplaybookの構築手法も取り入れた、より実践的な例をご紹介したいと思います。 構築する環境 構成図 以下の図のようにローカル、開発、ステージング、本番(図中ではそれぞれlocal、dev、staging、production)の4つの環境を構築し、Webサーバーではnginxとphpを稼働させ、DBサーバーではMySQLをmasterとslaveの構成で稼働させます。 構成概要

こんにちは。次世代システム研究室のJK (男)です。 突然ですが書籍の「ゼロから作るDeep Learning」読みましたか？基礎からクリアに説明されていて、個人的にはとても面白かったです。これまでLSTM, 強化学習の記事を書いてきましたが、今回はこの本にならってDeep Learningの基礎の「ちょい深」理解を目指し、Deep Learningの可視化に焦点をあてたいと思います。 ちなみに今回の内容のcodeは、ここに上げておきました。 0. 可視化のモチベーション 最近のDeep Learningのフレームワークは充実していて、簡単に動かせるようになりましたね。でも動かせたけど理解した気がしない、って人も多いのではないでしょうか？その理由の一つが、Deep Learningがブラックボックス化していることだと思います。簡単に動かせることの副作用だと思いますが、インプットデータと教師

2016.12.14 NativeBase Starter KitのUIコンポーネントをベースにReact Native開発を始める こんにちは。F.S.です。 もうすぐ年の瀬ですね。この1年を振り返ると、我々のチームではモバイルアプリの開発案件が（流れた話も含めて）だいぶ多くなりました。新規プロダクトゆえに、短期・低コストでの立ち上げが必要なものばかりだったと感じています。 ちょっと前に海外の記事で、ネイティブ開発したiOSアプリを要員追加せずに並行でAndroid版リリースおよびメンテしなければならなくなり、React Nativeで書き換えてうまくいっているという話がありました。どこも似たような境遇だなぁと興味を持って見てました。 我々の開発チームでは2015年5月にReact.jsを始めたこともあり、Android対応がリリースされた頃にReact Nativeを調査していましたが

Golangが一番パフォーマンスが良いかと予想していましたが、全く逆の結果になってしまいました。 Golangが遅い理由 遅い原因をいくつか考えて改善できないか試してみました。詳細は省きますが、以下の点については問題なさそうでした。 goroutineはリクエスト単位で起動している コネクションプールは有効になっている BeegoのORM特有の処理は主原因ではない(標準ライブラリのsql関数と大差なし) DB側のCPU使用率は100%になっているが、CPU使用率とメモリ使用量はPHP環境と同程度の負荷になっている ここまで確認して、プロファイラを使った方が良さそうに思えたので、いったんプロファイラで状況を確認するために、標準で提供されていて手軽に使えそうなpprofを使ってみました。topで確認すると次のような結果がでました。 (pprof) top 20 -cum 920ms of 15

直近はレガシー環境の改善に取り組んでいる D.M. です。今回は 2016 年 4 月に発表された Jenkins 2.0 を取り上げ、最大の特徴である Pipeline as Code について具体的な設定を解説します。 継続的インテグレーションツール戦国時代 継続的インテグレーション（以下 CI ）の自動化ツールは現状さまざま出ています。直近の私のチームがメインで使っている Bamboo は Atlassian 社製の有料ツールで、同社の Jira 、 Stash との連携機能を多く備えており、業務効率化に大いに役に立っています。また他の選択肢として Github との連携を謳った Travis CI 、 Circle CI といった有料サービスがあり、ある程度規模のある開発を行う際は高機能有料ツールを選択することが一般的な状況とも言えると思います。 こんな状況の中、 10 年以上の歴

次世代システム研究室アーキテクト兼データサイエンティストのT.Nです。 私は文系卒ながらもデータサイエンティストという役割を頂いている、いわゆる「文系データサイエンティスト」です 「文系でもデータサイエンティストにはなれる」と言われていますし、私もそうだと思っています ただ「機械学習や統計の理論を知らなくてもいい」というわけではありません 程度の差はあれ理論学習なくてして、分析を実施することはやはり難しいかなと しかし数学知識や理論、統計学の裏付けが無いためどうやったらいいか途方に暮れることもあるかと思います そんな環境に直面した私が機械学習関連の理論を勉強した際の方法を記載しようかと思います 同じ悩みを抱えている方の参考にでもなれば幸いです 目的 私と同じように文系卒でデータサイエンティスト職に就いている方、もしくはこれから機械学習関連の勉強をしていこうとしている方に対して 私の勉強法を

こんにちは。UI/UXD領域を担当しているT.I.です。 2月24日からGoogleの検索結果に導入されたモバイルサイトの高速表示化プロジェクトであるAccelerated Mobile Pages（以降、AMPと表記）ですが、当ブログもこれに対応してみましたので、フロント実装の内容共有エントリーです。 AMPとは Googleが推進するモバイルでの検索結果表示を高速化するためのオープンソース仕様に沿って作成された仕様です。Google側でAMP形式で書かれたウェブページをキャッシュすることで表示速度が向上できるというものです。 参考 Accelerated Mobile Pages プロジェクトについて — 導入ガイド日本語版を本日公開しました 過去の投稿をAMP化したもの(UserAgentをスマホにして確認ください) http://recruit.gmo.jp/engineer/ji

はじめまして。昨年12月から次世代システム研究室に入ったM.Mです。 昨年12月からある開発案件に携わることになり、そして今月、その案件の負荷試験を実施方法の検討も含め担当することになりました。 その案件ではもともとJmeterを使用した負荷試験をしており、以前作ったテストシナリオを流用できるとの話も聞いたのですが、私が過去に少しだけ使ったことがあり興味を持ったgatlingを使いたいという話をして今回の負荷試験ではgatlingを使わせてもらいました。 エンジニアのやりたい気持ちを前向きに考えてくれる次世代システム研究室に入ってよかったと感じました！ 前置きが長くなってしまいましたが、 今回は負荷試験ツールgatlingの紹介をしたいと思います。 目次 インストールは難しいのか？インストール方法について テストシナリオはどのように作るのか？ そして実行！ 結果レポートってどのようなものが

こんにちは、次世代システム研究室のN.O.です。 先日部内の研究発表会でブロックチェーンについての発表を行いましたので内容を共有したいと思います。 私の受け持ちとしてブロックチェーンの概要、またブロックチェーンを語るには欠かせないその発祥となったBitcoinについての説明を行いました。スライドのタイトルには「その未来」とありますが、未来の部分は今回は省略させていただきます。今後、別の機会で発表したいと思います。 イメージしやすいようにブロックチェーンを簡単な図にしたものです。 ブロックの中にトランザクションがこのように複数入ってます。 そこにブロックのヘッダとして前のブロックのヘッダのhashやnonce、マークルルートといったものが入ってます。 これらが一つになってブロックを成し、それらが鎖のように連なっていきます。 おおよそこのような形です。 ブロックのヘッダにはマークル木によって全

GMO スマートリザーブに React を導入 フロントエンドのトレンドを追いかけている D.M. です。 2015年の初夏ごろに次世代システム研究室が GMO スマートリザーブの立ち上げをサポートしました。 http://www.gmo-c.jp/service/smart_reserve.html こちらは店舗管理者がお店の予約を管理するためのシステムですが管理画面は Single Page Application となっており、 JS 部分に React を導入しています。今回はその案件で問題になった React と jQuery の共存について書いてみようと思います。 React を選定した理由 React については以前記事でまとめており概要は把握していました。 http://recruit.gmo.jp/engineer/jisedai/blog/react-refactori

こんにちは。次世代システム研究室のY.I.です。 最近参画した歴史あるプロジェクトで行ったトラブルシューティングの話題です。 アプリケーションの概要は CentOS 上の Tomcat で動作するサーバサイド Java アプリケーションとなっています。 今回は 「メモリ不足によるトラブルの対処」と「Java スレッドがデッドロックしてしまった件」をどのように調べて解決したかをお伝えします。 ◆メモリ不足によるトラブルの対処について 連携先との兼ね合いで Tomcat サーバから Apache サーバへ ssh して連携媒体と通信する機能がありました。こちらが2日に1回程度エラーになり Tomcat を再起動するまで失敗し続けるという状況になっていました。 エラーログ ERROR [InitAction.postProcess:132] ssh error web server ip=192

こんにちは、次世代システム研究室T.M です。 ※注意：本記事で書いてあるChrome の情報はベータ版の情報であり、また、2016年3月時点の情報です。最新の正しい情報は、適切な情報源から入手してください。 はじめに 昨年、Google からEddystoneという新しいBLE のプロトコルが発表されました。当ブログのEddystone に関する記事でご確認いただけるように、調査・検証をして参りました。特に、Eddystone-URL により、Physical Web の世界を体験できるようになりましたが、専用アプリではなくブラウザで対応をしていたのは、iOS のChrome であり、Android のChrome では非対応でした。しかし、先日、Android のChrome のバージョン49 からPhysical Web が対応するという発表がありました。そこで、早速Android

2016.03.11 実サービスで利用中のAnsible 1系をAnsible 2.0にアップグレードすると、何が起こるか？ 次世代システム研究室の DevOps ネタ担当の M. Y. です。 今年の1月に、構成管理ツール Ansible のメジャーバージョンアップ版である Ansible 2.0 がリリースされました。 この Ansible 2.0 では今後の機能追加を容易にするために、内部構造がほぼ一から書き直されています。その成果として、複数のタスクをまとめる block 構文や、200個を超える新規モジュールなど、多数の機能が追加されました。その一方、既存の playbook（処理内容が書かれた YAML ファイル）との後方互換性を維持することも、Ansible 2.0 の大きなゴールとして謳われています。 私たちも、いくつかのサービスで Ansible を実際に使用しており、そ

今回開発したWebサービスの特性上、1リクエストに対して1トランザクションで済ませられるのでトランザクション処理は共通のコントローラで一括して管理するようにしました。 Yii 2ではActive Recordが使えるので、モデルをActive Recordで実現するようにして、リポジトリとのやり取りを簡略化しました。そのため、エンティティとリポジトリをモデルの役割としてまとめるようにしました。 コントローラの処理 リクエストを受けたコントローラは大まかに以下の流れでリクエストを処理するようにしました。 集約のロード ビジネスロジック(サービスメソッドの実行) 集約の保存 表示データの構築 レンダリング 集約 概要 集約を導入すると次のような効果が期待できます。 トランザクション整合性が必要な属性をまとめることで管理しやすくなる 属性を集約にまとめることで属性の管理を集約間のやり取りとして簡

こんにちは。F.S.です。 前回のFirebaseに続き、今回もバックエンドサービスの話題です。 2014年11月のAWS Lambdaの発表（2015年4月に正式公開）により、サーバーレスアーキテクチャという考え方が登場しました。 サーバレスアーキテクチャとは、イベント駆動でクラウド上に登録したコードを実行できるもので、利用者がコードを実行するためのサーバインスタンスを構築・管理する必要がありません。 BaaSと比較されることが多いですが、BaaSはサービス提供者側の制約のもとに利用するもので自由度は少ない一方、サーバレスアーキテクチャは利用者がバックエンドのサービスを組み立てる分、自由度があります。サーバインスタンスを意識せずに、バックエンドでアプリケーション特有の処理を必要とするケースに利用されることになります。マイクロサービスの一種の形態とも考えられています。 2016年2月になり

こんにちは。F.S.です。 今回はFirebaseを使ったリアルタイムWebサービスの実装について紹介します。 https://www.firebase.com/ FirebaseはモバイルまたはWebアプリケーション同士のリアルタイムなデータ同期を提供するバックエンドサービスです。2011年にスタートし、2014年にGoogleに買収されています。 特徴 Realtime Database シンプルにすべてのデータ構造をJSONで表現します。 Firebase上で作成したアプリケーションのルートURLがJSONのルートオブジェクトに相当し、子要素に対してURLパスでアクセスすることができます。 各言語用に提供されるSDKを用いることで、任意のパス以下のデータをクライアントアプリケーションにリアルタイム同期することが可能となります。 各要素へのアクセス（Read/Write）はRuleで定

2015.12.22 スケールアウト可能なSQLエンジンのベンチマークテスト：Presto vs Spark SQL vs Hive on Tez １、初めに 次世代システム研究室のL.G.Wです。最近リリースした関連記事推薦システム：TAXEL byGMOに携わっております。 このシステムは多様なデータソースからの集計・解析・ETLが重要になるので、性能とビジネス要件を満たすSQLエンジンを選定するため、主要なSQLエンジンのベンチマークテストを実施しました。 “Small Start, Scale Fast” – 最初のハードウェアコストをなるべく低く抑え、ビジネスが拡大したらシステムも拡張できることが前提です。主にバッチ処理用途で、ある程度のリアルタイム性も要求されます（数分間～1時間内）。データの規模は数十GBから数TBくらいの想定です。 主要なSQLエンジンとして、スケーラビリテ

2015.12.21 HashiCorp製品（Vagrant, Consul, Atlas, Otto）の活用による開発環境構築の自動化について発表しました この記事は HashiCorp Advent Calendar 2015 の第22日目です（急きょ参加させてもらったので、公開日と1日ズレてます……）。 次世代システム研究室の DevOps ネタ担当の M. Y. です。今回は、2015年12月21日に開催された社内の研究発表会にて、HashiCorp の新ツール “Otto” に関する発表を行いましたので、その内容をご紹介します。 Otto とは、2015 年 9 月末に HashiCorp 社が発表した新しいツールです（参考：公式サイト、リリース時のブログ記事）。単一の設定ファイル “Appfile” で、開発環境と本番環境の両方を管理できる “The Successor to

この記事はApache Spark Advent Calendar 2015の18日目の記事です。 はじめまして。次世代システム研究室のT.Nです。 単語をベクトル化して、その類似度や加減算等の処理を可能にするWord2Vec 単体としてだけではなく、今ではSpark MLlibでも提供されているため、大量データでも取り扱いが比較的容易になっています 当記事では、そのSpark Word2Vecを用いて単語をベクトル化し、それをクラスタリング化することで単語をカテゴライジングする方法をご紹介したいと思います 処理概要 処理は大きく分けて２つの工程に分かれます WikipediaのデータをWord2Vecが処理できる形式に加工する Spark MLlib Word2Vec/K-Meansを使い、ベクトル化・クラスタリングを実施する なお、Inputデータはある程度大きなもの(加工後で100M

2015.07.01 ウォッチアプリはインタラクション(IxD)にフォーカスしたい件 – Apple WatchとAndroid Wearでアプリを試作してわかったこと こんにちは。UI/UXD領域を担当しているT.I.です。 モトローラ製のAndroid Wear「moto360」を使い始めてから、かれこれ9ヶ月経過です。 4月にリリースされたApple Watchは発売日から1週間ほど一緒に生活しましたが、「両腕に時計はさすがにいらないな」という付ける前からわかっていた理由で外しました。苦笑 さてさて、そんなApple WatchとAndroid Wearですが、概要理解を目的にアプリを作ってみました。 ウォッチアプリの概要 ・Apple Watch版、Androidwear版の両方を作る ・iBeaconとの距離を計測し、もっとも近い領域に侵入した際に画面を切り替える（トリガを叩く）

2015.05.28 謎の独自ERRORログをEmbulk + Elasticsearch + Kibana + PostgreSQLで監視する：運用設計からシステム構築まで 次世代システム研究室のDevOpsネタ担当（Embulkのコード読んでRuby復習中）のM. Y.です。 前回の記事（ERRORログが多すぎるWebアプリに出会ったら）では、ログ形式が統一されていない、大量のERRORレベルのログを吐き出すWebアプリに運悪く出会ってしまった場合に、そこから何とかログの傾向を把握するためのアプローチについてご紹介しました。 あれから、このアプローチを実践するためのログ監視システムを社内で実際に構築してみました。その結果、Embulk + Elasticsearch + Kibana + PostgreSQLという組合せで、割と手軽に、実用的なものを作れそうなことが分かりましたので、今