Embulkを活用してAmazon Elasticsearch Serviceへデータを同期させた話

こんにちは。インフラチームの高畑です。

今回は Elasticsearch (ES) を AWS に移行した際に導入した Embulk についてお話しします!

Embulkとは

Embulk とは、 Fluentd の開発者である古橋貞之氏によって開発された、 Fluentd のバッチ版のようなものです。 プラグインにより、インプットとアウトプットを柔軟に切り替えることが可能となっており、バルク処理に特化しています。

Fluentd と Embulk の違い
Fluentd
  • データのストリーミング転送
  • 既存の大量なデータは転送ができない

Embulk
  • 定期実行によるデータ転送
  • 分散処理により既存の大量なデータを転送できる

Embulkで利用できるプラグインは以下の通りとなっています。

プラグインの一覧はこちら

Input Plugin RDS、S3、GA、ES・・・・・
Output Plugin RDS、S3、GA、ES・・・・・
Filter Plugin カラムを削ったり、再構成したり
File Parser Plugin
File Decoder Plugin
File Formatter Plugin ファイル関係
File Encoder Plugin
Executor Plugin Hadoop上で実行させたり

導入前

これまで、サービスで利用する ES を自前で構築し、JDBC ドライバを利用して RDS から ES に対しデータを転送していました。 また、ログ基盤として EFK (ES + Fluentd + Kibana) をAWS のマネージドサービスを用いて構築を行なっていました。

サービスで利用する ES を AWS ES に統一しようと考えていたのですが、AWS ES は JDBC を利用したデータ転送が出来ないという問題があり、サービス用の自前 ES とログ基盤用 AWS ES が混在するという無駄な状態となってしまいました。

そこで、これらを解決するため、JDBC での転送をやめ Embulk を利用してデータ転送を行うことにしました。

f:id:tkhttty:20181005143003p:plain

導入後

Embulk の設定ファイルはとてもシンプルな構造となっており、 RDS からデータを取得して ES へ送るだけであれば以下のように設定するだけで動作します。

(括弧で括っているところは環境に応じて変更する必要があります)

f:id:tkhttty:20180921164109j:plain

Embulkを活用して 1 日 1 回の同期処理をさせることにより、AWS ES に RDS のデータを流せるため、自前の ES は不要になり ES の混在状態を解消することができました。

またこれにより、自前で ES を管理する必要がなくなり運用コストの低下にもつながりました。

f:id:tkhttty:20181005142043p:plain

おわりに

Embulkを活用することにより、自前で構築していたESを使う必要がなくなり運用コストの削減に繋げることができました。

同様なことで悩んでいる方がいらっしゃいましたらぜひ活用してみると良いかと思います!

アプリもくもく会を開催して感じたこと

はじめに

こんにちは。ウィルゲートで開発を行っている三島です。 私の所属するメディアチームでは「暮らしニスタ」や「Milly」などのメディアサイトの構築と運用を行っています。また、webサイトだけでなくwebViewではありますが、スマートフォンアプリの開発も行っています。

今回はメディアチームでアプリについて学ぶ時間として開催している「アプリもくもく会」について紹介していきます。

f:id:MikaE:20180906214635j:plain

もくもく会を開いた背景

アプリ開発は2016年から行っていますが、ウィルゲートではこれまでwebサイト構築を主に行ってきたため、アプリ開発についての知見がありませんでした。 これまではwebViewのアプリであったため、ネイティブアプリに比べ開発難易度が低く、なんとか調べながら開発を行っていくことができていました。

アプリができてから2年ほど経ち、アプリを使ってくださるユーザーが増えてきたため、 更に使いやすいアプリにするために、アプリをネイティブ化することが決まりました。

ネイティブアプリはこれまで作成してきたwebViewのアプリよりも難易度が高く、知らないことが多いです。そのため、これまでのようにトライアンドエラーを繰り返すことは効率が悪いと感じていました。 アプリ開発を1から調べながら学ぶことは効率が悪いため、ウィルゲートでは社外のネイティブアプリ開発に知見を持っている方にアプリの技術顧問として入っていただけることが決まり、アプリ開発についておしえていただけることになりました。 技術顧問についての詳細は下記の記事を見てください。

tech.willgate.co.jp

ネイティブ化に向けて技術顧問の方に入っていただき、アプリ開発における疑問点は解消できていますが、今後webViewからネイティブへ移行することでこれまでよりもアプリの保守工数が増加することが見込まれています。 しかし、現在チーム内でアプリの開発を行っている人が私以外にいないため、必然的に対応できる人も1人です。今後アプリを開発保守していくためにも、チームとして技術の底上げが必要だと感じていました。 チームとして技術を底上げするためにアプリについて学ぶ時間を作る必要があると感じていました。アプリについて学ぶ時間として勉強会やもくもく会などがありますが、メディアチームではもくもく会を開催することにしました。

勉強会ではなくもくもく会を開催することにした理由としては以下の2点です。

  • 勉強会の形式にもよりますが、もくもく会のほうが実際に自分でコードを書く時間が多く各自のレベルに合った勉強ができる
  • 各自で勉強をしてもいいが、勉強するためには強い意志が必要になるので集まって勉強をしたほうが続きやすい

もくもく会でやっていること

もくもく会では一般的なもくもく会と同じように時間が空いた人が集まって個人でアプリについて学ぶ場にしています。 ただ漠然とアプリについて調べたり、コード書いたりするだけでは効率が悪いので、mixiさんのiOSTrainingやAppleのswiftのチュートリアルなど基礎的なことを学ぶ事ができる資料を見ながら勉強しています。

iOSTrainingはXcodeの使い方やSwiftの書き方など基礎的なところから学ぶことができるため、初心者の方におすすめできる資料だと思っています。

GitHub - mixi-inc/iOSTraining: Training course repository for iOS app developmentgithub.com

Appleのswiftのチュートリアルは英語で書かれているため読むことに時間がかかってしまいますが、簡単なCRUDのアプリを作ることができるため、楽しく学ぶ事ができるのでおすすめです。

developer.apple.com

もくもく会の感想

良かったこと

良かったこととしては、チュートリアルを進めていくことで基礎的な力はついたと感じています。また、これまで1人で勉強をしていたため疑問の解消に時間がかかっていましたが、チームで勉強を行うことで他の人に質問をすることができ、より効率よくアプリ開発について学ぶことができています。特にこれまで1人で調べ1人で解消していたため孤独を感じていましたが、雑談しながら勉強することで楽しく勉強ができ良かったと思います。 時間を作って参加してくれたチームメンバーには感謝しか無いです。

反省点

チュートリアルをこなすことで基礎は学ぶ事ができたと思いますが、実際のプロダクトコードでは応用が求められます。もくもく会チュートリアルで学んだことを実際に使ってみることができなかったです。今後は実際に題材を決めアプリを作ってみるなど応用を学ぶ事ができるように工夫していきたいです。

まとめ

アプリもくもく会を始めて3ヶ月経ち、全体として基礎的な知識はついてきたと感じています。 今後こういった活動を続けていくことで、ウィルゲートの開発組織全体としてwebアプリだけでなくネイティブアプリを開発できるようになり、より多くの人にサービスを利用してもらえるようにしていきたいです。

Chrome DevToolsを使用してサイトのパフォーマンス改善をしてみた

こんにちは!開発室メディアユニット所属新卒1年目の小澤です。
ウィルゲートでは現在(2018年9月1日)4つのメディアを出版社と協業で運営しており、そのうちの3つを自社で開発、運用・保守しています。

暮らしニスタ|知りたい!教えたい!暮らしのアイデアがいっぱい!

Milly ミリー|妊娠・出産・子育ての“今知りたい”をすぐ解決

花時間 | 花やグリーンから始まるボタニカルライフの提案

PV数や回遊率を上げるためには良質なコンテンツを提供するのはもちろんですが、その他にできる取り組みとして、UI・UXの改善、表示速度のチューニングなどがあります。
今回は、ページの表示速度を改善する一歩目として、webブラウザGoogle Chrome」に標準で搭載されている 「Chrome DevTools」を利用して簡単にサイトスピードを計測する方法を紹介します。

Chrome DevTools(旧:DeveloperTools)とは?

Googleの開発者向けサイト、Google Developersによると、

Chrome DevTools は、Google Chrome に組み込まれたウェブ作成およびデバッグツールのセットです。 DevTools を使用してサイトの反復処理、デバッグ、プロファイリングを行います。

と書いてあります。
詳しくはこちらをご覧ください。

developers.google.com

具体的な用途としては、表示崩れの原因特定、JavaScriptデバッグ、表示速度のチューニングなどがあります。
webエンジニアなら一度は使ったことがあるのではないでしょうか。
非常に多機能で本記事では紹介しきれないので、表示速度の計測方法に絞って紹介します。

表示速度の計測

今回は自社で開発、運用・保守している暮らしニスタの速度を計測します。

現在の表示速度を計測する
  1. Google Chromeで計測したいページを表示させます。
  2. Chrome DevToolsを表示させます。
    Chrome DevToolsはコンテキストメニューかキーボードショートカットから表示できます。

ウィンドウ上部にパネル名があり、標準で9つの機能がそれぞれ強力な機能を提供します。
速度を計測するためには、「Performance」タブを選択します。

google dev toolsの画像

Performanceタブ右上の歯車マークをクリックすると計測時の設定ができます。

f:id:rikipedia-5r:20180903210821p:plain

Network

計測する際の回線速度を設定できます。デフォルトは「Online」で、速度はPCが接続しているネットワークに依存します。他にも「Fast 3G」「Slow 3G」「Offline」がプリセットとして用意されており、カスタム設定もあります。

CPU

Google Chromeに割り当てられたCPUリソースの使用量を設定できます。デフォルトは「No throttling」で、特に制限は設けません。他にも「4× slowdown」「6× slowdown」がプリセットとして用意されています。

今回の計測での設定は次のようになります。

対象ページ バイス 回線速度(上り) 回線速度(下り)
https://kurashinista.jp PC 97Mb/s 97Mb/s

回線速度を一定にし、PC版の暮らしニスタトップページを計測してみます。

計測してみる

それでは早速計測してみましょう。
Performanceタブ左上の更新マークをクリックすると計測が始まります。

f:id:rikipedia-5r:20180903211226p:plain

ページによっては計測に時間がかかるのでしばらく待ちます。

f:id:rikipedia-5r:20180903211035p:plain

計測が終わりました!

f:id:rikipedia-5r:20180903211412p:plain

計測結果の詳細を説明します。

f:id:rikipedia-5r:20180903212021p:plain

①:レスポンスからページの表示が完了するまでに何が起こっているかの概要が分かります。
縦の赤線が引いてある箇所は、ページの表示が完了した時点を表しています。
赤線が引いている箇所を左端までドラッグすると、ページの表示が完了するまでの数値が分かります。 上記画像では700msあたりからページの描画が始まり、赤線が引いてある3200msあたりで表示が完了しています。

②:①で選択した範囲で何が起こっているかの詳細が分かります。
Summaryタブでは、大きく分けて6つの数値を見ることができます。

Loading

与えられたURLからHTMLを読み込んで、そこから更にレンダリングに必要な付属するリソースを読み込んで解釈していきます。 このフェーズでは主にリソースのダウンロードとパースを行います。 リソースを一式読み込んだ後、JavaScript実行(Scripting)へ移行します。

Scripting

レンダリングエンジンが、JavaScriptのコードをJavaScriptエンジンに引き渡して実行させます。

Rendering

JavaScriptの実行が終わると、今度はレイアウトツリー構築(Rendering)に移行します。この中ではスタイルの計算(Calculate Style)とレイアウト(Layout)という2つの処理が行われます。

Painting

DOMツリーのレイアウト情報の算出が終わると、最後のレンダリング結果の描画(Painting)に移ります。このフェーズでようやくレンダリングエンジンはユーザーが見ることができる実際のピクセルを描画します。ここでは、ペイント(Paint)とラスタライズ(Rasterize)とレイヤーの合成(Composite Layers)という3つの処理が行われます。 最後のComposite Layersが終わることで、ユーザーの目にはレンダリングエンジンが描画した画面が表示されます。

Other

JSエンジンのイベントループに対するオーバーヘッドの時間です。

Idle

JSやCSSなど、リソースをダウンロードしてからレスポンスが返ってくるまでの待ち時間です。

(以下から一部抜粋)

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

計測結果
Loading(ms) Scripting(ms) Rendering (ms) Painting(ms) Other(ms) Idle(ms) 合計(ms)
976.0 1215.8 330.7 57.2 578.6 720.6 3,000.5

ページの表示が完了するまでに約3秒かかっています。 日本ラドウェア株式会社の調べによると、操作開始時間の理想的な数値は3秒だと言われています。 ぎりぎり3秒台なので及第点ですね。

webtan.impress.co.jp

ちなみに理想は表示速度が爆速で有名な阿部寛のホームページです(笑)。

f:id:rikipedia-5r:20180903214442p:plain

同じ条件で計測してみたところ、暮らしニスタの約15分の1でした。道のりはまだまだ長そうです。

ボトルネックの特定

約3秒の内訳の内、40%がScriptingに使われています。 Scriptingは、先程も述べたようにJSの構文解析を行うフェーズです。 つまり、JSの容量が大きいとそれだけ読み込みにかかる時間も増えるということです。

Scriptingに問題があるということがわかったので、次に実際にボトルネックとなっているファイルを特定します。

Summaryと同じタブの「Call Tree」タブを選択します。 次に、列「Activity」の「Scripting」を選択します。 そうすると、Scriptingの中で具体的にどのイベントにどれだけ時間がかかっているかが「Evaluate Script」で分かります。

f:id:rikipedia-5r:20180903220157p:plain

青枠で囲ったあたりが今回のScriptingの大半を締めているので、この箇所がボトルネックであると分かります。 ちなみにボトルネックのファイルをたどったところ、どうやら広告の読み込みに時間がかかっていたようです。 さらにどのファイルのどこがボトルネックであるかを調べるにはJSプロファイラを利用して特定することができますが、今回の本題とは別の話なので割愛します。

対策

広告の読み込みに時間がかかっていることがわかったので、各広告の読み込みにかかる時間を計測し、 とりわけ時間のかかっている広告は一旦取り外し、その他にはasync属性をつけることによって広告の読み込みでrenderingをブロックせず、documentの解析が終わったらscriptを読み込むようにしました。 この対策によって、広告の読み込みにかかっていた時間を大幅に短縮することができました。

最後に

今回はChrome DevTools使った簡単な速度の計測方法を紹介しました。 計測の方法は他にもたくさんあり、上記のようなやり方が正解とは限りません。 ちなみにGoogleが公式で推奨しているパフォーマンスの分析方法なども紹介されていたりします。

developers.google.com

あくまでも参考程度に考えておくと良さそうです。

おまけ:速度計測の自動化

Chrome DevToolsを使い、何回か計測した平均などを求めたい場合、出力された数値を毎回コピペするのはとても煩雑で手間がかかります。 そこでおすすめなのが、サイトスピードを自動で計測し、リッチに表示してくれるsitespeed.ioです。

f:id:rikipedia-5r:20180903223058p:plain

コマンド一発で指定したURLに対して計測を自動で行います。 計測する際にはヘッドレスブラウザを使用し、詳しい値を計測しています。 他にもユーザーエージェントの選択やBasic認証などにも対応しているので、とても便利です。

それでは良い開発ライフを!

Fluentd(td-agent)とNorikraを活用したDoS対策をメディアに導入したお話

こんにちは。インフラチームの高畑です。

今回、弊社で運営しているメディアに Fluentd と Norikra を活用した DoS攻撃対策を導入したのでご紹介いたします!

導入に至った背景

これまでは Apache のモジュールである「mod_dosdetector」を利用して DoS攻撃の対策を行なっていました。

mod_dosdetector とは
同一 IP アドレスから一定回数のアクセスがあった場合に、環境変数「SuspectDoS」または「SuspectHardDoS」をセットするモジュール。
セットされた環境変数の値を使い、「mod_rewrite」で DoS攻撃と判定されたアクセスを 503 へリダイレクトさせることによりアクセスを遮断する。

しかしながら、 mod_dosdetectorApache 2.4 以上には対応していないため、最新の Apache を導入している場合などには利用ができませんでした。 また、全サーバに対してアクセス制限ができない、ファイアウォールで防げないという問題もあり mod_dosdetector の利用を諦めることになりました。

そこで、ログ収集管理ツールであるFluentdとログのストリーミング解析ができるNorikraを活用して DoS攻撃対策を行うことにしました!

Fluentd とは
全てのログをJSONとして扱うことを目的として開発されたログ収集管理ツール。
入出力のプラグインが豊富で、S3やElasticsearchなどにもログを送信することができる。
Norikra とは
Norikra is an open-source Stream Processing Server with SQL.

・Schema-less event streams (called as 'target')
SQL processing with window specifier supports, and JOINs, SubQueries
・Complex input/output events with nested Hashes and Arrays, and Query supports
・Dynamic query registration/removing, without any restarts
・Ultra fast bootstrap and small start
・UDF plugins

公式githubより引用)

Fluentd + NorikraでDoS攻撃の対策をする

当初、 Norikra で検出されたイベントを各サーバが取りに行く構成にしようと思っていたところ、一度でもイベントを取得したらそのイベントは消え、そのほかのサーバがイベントを受け取れないという状況になりました。

そのため、下図のような構成に変更を行いイベントを受け取る Fluentd を Norikra サーバに同居させることになりました。

f:id:tkhttty:20180907113546p:plain

  1. Norikra サーバに対して各メディアのフロントサーバから Fluentd でアクセスログを送信
  2. ログを受け取った Norikra サーバは登録された SQL をもとにアクセスログを解析
  3. 検出されたイベントを Norikra サーバの Fluentd でキャッチし、各サーバに対してイベントを送信
  4. イベントを受け取った各サーバはシェルスクリプトからファイアウォールに該当 IP アドレスを登録
  5. 一定時間が経過したらアクセス制限を解除

これにより、検出された IP アドレスに対して全サーバで同時にアクセス制限をかけることが可能となりました。

おわりに

Fluentd と Norikra を組み合わせることにより、すごく手軽に DoS 対策を行うことができました。

NorikraでDoS攻撃を検知した際に Slack やメールで通知を行うこともできるので、より早く発見できるようになりました!

AWS Shield などのサービスが使えないような環境にはとてもおすすめです。

スマホアプリ内製化に向けた取り組み!アプリ技術顧問に参画いただきました

はじめに

はじめまして!メディアユニットでマネージャーをしている福原です。 メディアユニットでは毎日の生活をもっと豊かにするアイデアメディア『暮らしニスタ』をはじめ 複数のメディアサービスの開発を担っています。

本ブログでは暮らしニスタのスマホアプリリニューアルにあたって アプリ技術顧問に参画いただいた話についてご紹介いたします。

技術顧問を採用した背景

『暮らしニスタ』は二年前にほぼwebviewのiOS/Androidアプリを 当時在籍していた業務委託の方に2ヶ月で作っていただきリリースいたしました。

ただウィルゲートは以前からwebを中心に事業拡大してきた背景があり、webの開発においては社内にかなりのナレッジが貯まっているもののスマホアプリ開発に関しては一切のナレッジがありません。 したがってリリースしてからの二年間、半ば放置に近い状態で温めてまいりました。

ただそんな中でもアプリを使ってくれるユーザーさんが多数おり、そのユーザーさん達に長い間『暮らしニスタ』を使い続けてもらえるように、また他のメディアサービスでもアプリ化構想があり社内にアプリ開発・運用のナレッジを蓄積したいということでアプリをリニューアルすることになりました。

右も左もわからない中で時間を掛けて自分たちだけで一からリニューアルするよりも、専門家の方に知見をいただきながら進めていく方が、期間や品質、その後の保守も含めればコストの面でも良いという判断でアプリの技術顧問採用にいたりました。

技術顧問の採用軸

技術顧問を採用する上で以下4つスキルを重視して選定いたしました。

1.アプリ開発の技術選定スキル(重要度:高)
Swift, Objective-C, Java, Kotlin, ReactNativeなどなど多様な言語やフレームワークがあるなかで、それぞれのメリデメを理解しており適切な技術選定が出来る(アドバイス出来る)

2.アプリ開発の設計スキル(重要度:高)
チーム・アプリの規模・メンバーの習熟度などを踏まえた上で運用効率の高い設計、複数メディアに展開する上で汎用性の高い設計が出来る(アドバイス出来る)

3.アプリ開発の実装スキル(重要度:中)
現役でアプリ開発を行っており、鮮度の高い技術指導が出来る。コードレビューが出来る

4.アプリのグローススキル(重要度:低)
アプリのリテンション向上やインストール数を伸ばすノウハウを持っている

また上記以外でもウィルゲートと同様の課題を抱えた会社の顧問経験であったり、ご指導いただく上でコミュニケーションが取りやすい(人柄的に)など様々な観点で選定させていただき、 株式会社サーキュレーションhttps://www.circu.co.jp/)にご紹介いただいたラグナロク株式会社(https://ragna-rock.com/)の西本誠さん(以下、西本さん)にお願いすることにしました。

f:id:akys-fkhr:20180904111452j:plain

技術顧問との連携方法と具体的な相談内容

基本的には週1回来社いただき1時間半のMTGを実施する形式をとっています。またSlackでも必要に応じて都度コミュニケーションをとっています。

具体的な内容としては大きく2つに分類できます。 1.開発の進め方について相談・ディスカッション 2.開発を進めていてわからないことを質問 進め方を相談した上で一週間開発を行い、そこで出た疑問や問題点を翌週に質問するという流れで進めていました。

開発の進め方について相談・ディスカッション

例)
・設計していく上でアーキテクチャどう選定すればいいですか。(MVC,MVP,MVVMなど)
ディレクトリはどういう分け方をするのがいいですか。
・共通処理はどこに書くのが適切ですか。
・StoryboardとViewControllerでどう役割を分けるべきですか。

開発を進めていてわからないことを質問

例)
・複数のcollectionViewが存在する場合にDelegateはどこに記載するべきでしょうか
・StoryboardのViewで選択したdevice幅でビルドされてしまいます
・iOS9の場合にAutoLayoutで制約の重複が発生しcrashしてしまいます

その他こんなことを質問してました

例)
・コーディング規約ってどうやって決めていけばいいでしょうか
・初心者が学習を進める上でおすすめの方法はありますか
・データ分析は何のツールを使っていますか
・デプロイツール何使っていますか

f:id:akys-fkhr:20180904111253j:plain

まとめ

アプリ技術顧問の西本さんに参画いただいてから約3ヶ月。技術選定・設計が終わりネイティブページ開発やPush通知構築を進める中でアプリ開発内製化に確かな手ごたえを感じています。 求めていたアプリ開発についてはもちろん、それ以外にもアプリ業界の動向や他社事例などを幅広い知見をいただけており技術顧問の西本さんに参画いただいて本当によかったなと思います。 また技術獲得のため顧問採用に投資してくれる会社の方針・文化も本当にありがたいですね。 今後アプリ以外の分野に関しても、こういった形で更なる技術力向上を検討すべきだと思いました。

SQSで処理を非同期化したらストレスフリーになった

f:id:cocoeyes02:20180725091923j:plain

こんにちは。サグーワークス開発チームに所属している大津です。

サグーワークス開発で Amazon Simple Queue Service (以下 SQS と呼ぶ)をサービスに導入したので、SQS の紹介と実際に導入した例を紹介したいと思います!

今回は他のメッセージキューイングサービスなどには触れず、あくまで SQS にテーマをしぼってお話ししていきます。

SQS とは?

SQS は AWS ( Amazon Web Services )が提供しているメッセージキューイングサービスです。

キューへメッセージを送信、あるいはキューからメッセージを受信・削除をすることができるシンプルなサービスになります。

キューを介してメッセージを送受信することで、異なるシステム同士でデータの送受信ができます。

メッセージキューイングサービスのメリット

メッセージキューイングサービスの最大のメリットは、システム同士が同期していなくてもメッセージのやりとりができることにあります。

それぞれシステムが好きなタイミングでメッセージを送受信することができます。

SQSを導入 -導入背景-

CRM からサグーワークスへ自動で情報を登録したい

サグーワークスには運営者用の管理機能があります。

それとは別に、CRMでも情報を管理しています。

サグーワークス上でも CRM で管理している顧客情報が必要だったので、CRM からサグーワークスへ手動で顧客情報を登録していました。

以下がその手順と図になります。

f:id:cocoeyes02:20180904095301p:plain

  1. CRM から サグーワークス DB に保存したい顧客情報を確認する
  2. 管理画面から手動で顧客情報をサグーワークス DB に登録する

手動で顧客情報をサグーワークス DB に登録するため、この方法では手間がかかるという問題がありました。

そこで、自動化も含めて運営者用の管理機能をリニューアルしようという話になりました。

仕様変更の影響を減らしたい

自動で顧客情報をサグーワークス DB へ登録するにあたって1つ問題がありました。

CRM でデータの持ち方に関する仕様変更があったとき、サグーワークスのシステムでもあわせて変更する必要がありました。

どう解決するか悩みましたが、「ロジック」と「タイミング」2つのアプローチで仕様変更の影響を減らすことに決めました。

ロジックを分けて疎結合にする

CRM 周りのロジックは「 CRM から顧客情報を取得するロジック」と「取得した情報を保存するロジック」の2つに分けて疎結合にします。

もし CRM 側で仕様変更があっても、「 CRM から顧客情報を取得するロジック」だけ修正すれば対応することができます。

タイミングを分けて処理を非同期にする

CRM への顧客情報を取得する処理とそれ以外のサグーワークスの処理を非同期にします。

そうすることで、CRM への顧客情報を取得する処理でエラーがあっても、それ以外のサグーワークスの処理は実行されます。

これで、他の処理まで実行できなくなるという事態を避けることができます。

条件を満たしたい

「ロジックを分けて疎結合にする」「タイミングを分けて処理を非同期にする」を満たす方法を調べました。

すると SQS を利用すれば上記の条件を満たせることがわかり、SQS を利用することに決めました!

SQSを導入 -利用例-

サグーワークスの運営者用の管理機能を使って顧客情報を登録するとき、手動で CRM に顧客情報を確認しなくても良いように、顧客情報を取り込むバッチを作成しました。

以下がその手順と図になります。

f:id:cocoeyes02:20180904095035p:plain

  1. 管理画面から顧客を指定し、メッセージ(顧客 ID )を SQS に送る
  2. バッチが SQS からメッセージ(顧客 ID )を取得する
  3. バッチが顧客 ID を使って顧客情報を CRM から取得する
  4. バッチが顧客情報をサグーワークス DB に登録する
  5. サグーワークス DB に登録に成功した時は、バッチが登録成功した(あるいは既に登録されている)メッセージ(顧客 ID )を SQS から削除する

バッチと SQS を使うことで、CRM 関連の処理とそれ以外の処理を非同期化することができました。

終わりに

CRM など外部からの仕様変更の影響を減らしたい時には、SQS はとても有効です。

皆さんも是非、プロダクトに導入してみてはいかがでしょうか!

責任範囲の拡大!インターンの経験を活かした入社3ヶ月とこの先の目標

こんにちは。 2018年にウィルゲートにエンジニアとして入社した林です。 現在コンテンツマーケティング事業を支えるシステムの開発・運用保守を行っているチームに配属されています。

入社して早3か月が経ちました。 自分はウィルゲートに入社を決めた後、大学の夏季休業中約2ヶ月ほど現在の配属先と同じチームでインターンをしていました。 インターンの期間と入社後の期間が同じのため、今回のブログではインターン時代と入社後の業務内容を比較し、振り返ってみようと思います。

入社経緯

まず、自分は今回初のブログ投稿でもあるため、簡単に入社経緯を書こうと思います。

自分が在籍した大学の学類では、幅広い技術の基本を学ばせた後は、そこから先は個人の自由にやっていく風潮がありました。 そのため、大学時代で触れた言語だけでもjavaC言語OCamlR言語アセンブラ言語といった計10近くは触れていたと思います。 講義でも、機械学習や組み込み技術、CGとバックエンドの技術をメインに学びました。

学外での活動ではゲームを作成したり、Arduinoで遊んだりとwebとは全く関係ないことをしてきました。

大学時代に様々なことをやっていた自分ですが、大学入学前はゲームエンジニアを目指していました。 大学入学後、講義を通して様々な技術に触れていくうちに、将来の職としてゲームエンジニアと絞らずに、色んなことが経験でき、顧客との距離が近く、お互いに成長していけるような会社で働きたいと変化しました。 そのため、就活時にはゲーム会社のほかに、セキュリティ会社やweb会社といった幅広い分野の会社を見ました。 その際に会社を見る指針として設定したのが、 ・自社でメインに開発を行っている ・二つ以上の分野に手を伸ばしている といった2点でした。

そういう指針をもって就職活動をしている中で、最終的にウィルゲートに入社することを決めた大きな理由として

  1. 開発において全て自社内で行っているため、幅広い経験ができそう
  2. 社長研修や上長との1 on 1といった社員一人一人に向き合った制度があり、内定をもらった中で最も自分が楽しく、成長できる
  3. 兼任制度や新規事業の提案制度があり、自分がやりたいことを実現できる
  4. コンテンツマーケティング事業、メディア事業の2つが存在する

といった4つの理由があり入社を決めました。

インターン時代

業務内容

自分がウィルゲートでインターンを開始した時期は、チーム内で大きなシステムの社内リリースを控えていました。 そのため、インターンの最初からプロダクト開発メンバーの一人として参入し、業務はバグの除去を任されました。 最初は、システムを理解することもあり、リストアップされたバグを簡単なものから順に取り除くことに力を注ぎました。 途中からは自分でバグを見つけて、上長に確認し、それらを修正していくこともしていました。 バグの種類としては、簡単なものではデザイン修正・表示の出し分け、 少し大変だったものでは、画面遷移時に前の画面情報をもとにして初期表示の変更・自分で仕様変更による処理を考えて実装などがありました。 以上のようなバグを約50個、インターンの期間中に取り除くことができました。

その後は、簡単な実装を任せてもらえました。 その内の一つにVue.jsを用いてselect2を実装するというのがありました。 select2とはjQueryプラグインで、selectタグを使いやすく高機能にしたものです。 この実装では描画自体は順調でしたが、選択時のイベントが動作しないということがありました。 調べたり、先輩に話を聞いたりしてなんとか実装を完了しました。 現在でも、そのとき書いたコードが残ってたりするので毎回その部分を見ると少し心がほんわかしたりします。

以上のことを行って、自分は約2ヶ月間のインターンを終えました。

学んだこと

自分はウィルゲートでインターンを行うまで、webの開発もそうでしたが、チームでシステムの開発を行うことをやったことがありませんでした。 最初は、他のメンバーの進捗状況を考えずに、様々なファイルに修正を加えるプルリクエストを出してしまうことがありました。 また、コード規約に沿っていないといったことがあり、プルリクエストのコメントが何十件になったこともありました。 その際に、チームの人にプルリクエストの単位を小さくすること、読みやすいコーディングの必要性を教えていただきました。 教えてもらった後からはただ実装するだけでなく、どうしたら読みやすいのか、他の人が出したプルリクエストを見て参考にしたりと注意を行うようにしました。 そのおかげもあり、今まで目の前のことしか見えていなかったものが、少しずつ視野を広く持つようになり、自分が行う修正が他の人にどのような影響があるのかを見れるようになったと思います。

f:id:rinrin_wg:20180824185517j:plain

入社後

業務内容

インターンの時は、一つのシステムのバグ改修がメインでした。 入社後では、チームが持っているシステム全般の開発・運用保守をメインに行っています。

現在、自分のチームで扱っているシステムは全部で9個程あります。 自分はそれらすべてのシステムの運用保守を行いながら、どういうシステムか、どのような処理手順かといった理解を進めています。 最初は上長から直接エラーの対応を任されていました。 しかし、そのまま上長から直接作業を任される状態に慣れてしまうと、自分の成長も望めません。 更にチームへの貢献も多くできないとも思いました。 その考えが出てからは、エラーが出ていることに気づいたら、事前に原因がなんだったのかを調べて、上長に自分が対応する旨を伝えるようにしました。 最初は、エラーとは的外れの場所を調査することがありましたが、何度も対応していくうちにエラーの原因箇所をすぐに割り出せるようになっていきました。 また、その際に行ったことや手順などをドキュメントに残し、属人化とならないように注意しています。

開発に関しては、現在開発中のシステムへの機能の追加をメインに行っています。 この現在開発中のシステムというのが、社内の中でも今後「コンテンツマーケティング事業を支えるシステム」の根幹となるものでもあります。 基本的には機能追加に最長3日もあれば実装が完了するものを割り当てられています。 大学時代では個人で開発することを行っていたため、チームで開発するときの留意点や大変さを感じることができ楽しいです。 また、現在任されている主要システムの内一つに、他のチームも使い、かつ社内でも核となるシステムがあります。 チームに配属されたばかりの頃、このシステムの改修を任されました。 このシステムに不具合や修正があった場合は当然ながら社内全体に影響が出ます。 そのため、インターン時に任された業務と比較すると想像つかないほど緊張しながら開発・テストをしていました。 しかし、その分とてもやりがいもありましたし、テスト時に注意すべき観点といった得るものが多くあったと思います。

f:id:rinrin_wg:20180824185601j:plain

インターン時代との変化

正社員となり、インターン時代と異なって大変になったことが2点あります。

一つ目は責任範囲の拡大です。 インターン時代も自分が修正した部分に責任を持っていました。 その際は、大きなプロダクト開発の一メンバーとして、システムを早期に理解し、バグをたくさんつぶして活躍をしていました。 社員となったことで、扱うシステムの範囲も広がり、基幹システムの修正を任されたり、基本設計から携わったりと、他のメンバー、チームとも触れる業務が増えました。 まだ慣れていないことで見落としがあり指摘されることはありますが、任されているということが実感できています。

二つ目は外部の仕様変更による影響範囲の認識です。 入社してから機能の実装部分に携わることがありました。 入社して最初に任された最初の業務では、社内で基幹となっているシステムに機能を追加しました。 テストも行い無事リリースとなりましたが、その数週間後にエラーが大量に発生することがありました。 自分が任された部分でもあったため、自分がミスをしたと思い心臓がバクバクでした。 調査を通して何が原因だったのか追求しましたが、最終的にエラーの原因は外部APIの仕様が突然変更となったことでした。 しかし、この現象が起きたおかげで、その後の運用保守や実装の際に外部APIのことも考えながら作業を進めることができるようになりました。

まとめ

現在自分は、業務では重要なシステムの運用保守や開発に関わることが多いです。 そういう役割を任されているのも、インターン時代にインターン生という気持ちを捨て、自ら問題を見つけようとしたり、システムの理解をしようとしたため、信用を得るこができていたからだとも思っています。 また、インターン時代には、実装時の注意点や周囲のチームメンバーを考えるといったエンジニアとして注意する中で基本となる部分を身に着けることができました。 入社してからも、インターン時代に得た経験が更にブラッシュアップを行っていますが、まだ依然として先輩方から何かを得ている段階であります。 今後は誰かに自分がインターン時代や入社して得た経験を普及したり、取り組み方の手本となれるように頑張っていきたいと思います。

今後

自分のチームでは突発的に扱っているシステムに対して相談や依頼がくることがあります。 それらの窓口は現在上長となっており、その対応も上長が行っています。 この窓口と対応を行う流れを自分が担えるようにすることを第一の目標としています。 そのために、まずは現在稼働している社内システムを他人に説明できるぐらいに理解を進め、 運用保守や依頼があった際には自分が率先して行うようにしていかなければならないと思っています。

また、開発の部分では現在小さいタスクが割り振られています。 少しずつ大きなタスクが任されるように信頼を得て、基本設計や要件定義などの上流に関われるようになりたいと思っています。

短期的な目標としては、早く他のメンバーと同じぐらい社内システムを理解し、基本設計から関われるように今足りない力を手に入れていきたいと思っています。

長期的な目標としてはPMとなり、プロダクトを回していけるようになることを目標としています。そのために、エンジニアとしての技術力を身に着けることはもちろん、思考の柔軟性、スケジューリング力をつけていきたいと思っています。