コネヒト開発者ブログ

コネヒト開発者ブログ

Connehito Marché vol.6 〜機械学習・データ分析市〜 を開催しました!

f:id:taxa_program:20191108125429p:plain

こんにちは。MLエンジニアの野澤(@takapy0210)です!

11月に入っていよいよ寒くなってきましたね。
寒いといえば、毎朝洗濯物を干すのが辛くなる季節でもあります。
このような季節も影響し、我が家ではドラム式洗濯機のデプロイが検討されています。もしオススメのドラム式洗濯機があれば教えてください!!

さて今回は、先日無事に開催することができました、「Connehito Marché vol.6 〜機械学習・データ分析市〜」の様子や、LTの内容などを簡単にご紹介できればと 思います!
(嬉しいことにLT枠もオーディエンス枠も満席となり、大盛況で終えることができました!)

connehito.connpass.com

今回のテーマ

今回は第6回目ということで「機械学習・データ分析」をテーマとして開催しました。

抽象的なテーマだったため、LT内容含めてどのような方々が参加してくださるのか、非常に楽しみでした!

ちなみにコネヒトマルシェでは毎回テーマを変えており、過去には下記のようなテーマで開催しています。

今回は、下記3つのお願いお伝えした上で、スタートさせていただきました!

f:id:taxa_program:20191108130206p:plain

LT内容

データ分析コンペにおいて特徴量管理に疲弊している全人類に伝えたい想い

by @takapy0210

概要

  • データ分析コンペをnotebookだけで挑むといろんなツラミがある
  • 特徴量管理とパイプライン組むとちょっと良くなった
    (初っ端から時間オーバーしてすみませんでした。。。)

SageMakerで構築する価格推定システム

by @0xb5951さん

www.slideshare.net

概要

  • 機械学習でなんかやってみてよと言われてやった
  • 依頼がいくらで成約するかを推定
  • SageMakerを用いて手早く実装した
  • 今日リリース予定だったが、リリースできず

社内での円滑なデータ分析のために

by @yu__ya4さん

概要

  • データ分析業務のポジティブな社内政治のお話
  • 直接関係のないPJなどにも顔をだしたり、ランチに行ったりコミュニケーション取るのがめっちゃ大事(何やってるかわからない人にならないためにも)
  • 結果として社内外でのプレゼンスが向上しいろんなことが円滑に進んだ

初めて機械学習PJをやってみて得た知見

by @yaginuuunさん

概要

  • 自社サービスにレコメンドエンジンを入れた
  • 簡単でも良いので、まずは結果を見える形にする
  • Kaggleは役に立つ

SIGNATEの練習問題コンペで 57位までスコアを上げた話

by @shnagaiさん

概要

  • 機械学習勉強しはじめて初めて自分でモデルを作った
  • あとで分析結果などを見返したい時のために、メモを取るのが大切
  • ドメイン知識をフル活用して、スコアを向上させた(57位/1748)

BigQueryいいよね!って話をしようと思ったらBigQueryより早いAzure Synapseが出た

by @YASU11552288さん

概要

  • BigQuery良いよね、という話をしようと思っていたら、75倍速いAzure Synapseが出たので、急遽内容を変更
  • Azure Synapseはインスタンス単位の課金でインデックスのチューニングが必要
  • 導入を考えるとすこし運用コストが高そう

日本語学習済みモデルについて

by @TwYamatさん

docs.google.com

概要

  • 今はBERT が微笑む時代
  • 学習済み言語モデルのGood / Badポイント
  • 日本語学習済みモデルを使用すれば、様々なNLPタスクに取り組める一方で、日本語の学習済みモデルが少ないので、適応するには制限がありそう

Meta Kaggleを覗いてみた

by @IshizakiYukoさん

概要

  • Kaggleって本当に流行っているか、Meta Kaggleを覗いて調べてみた
  • 新規ユーザーは右肩上がりの一方、コンペにSubmitしているユーザーで分析してみると、鈍化している
  • 最近は画像コンペが増えている
  • kaggleの沼にはまろう

NGBoost論文読んでみた

by @ml_taroさん

概要

  • kagglerにも人気かつ、つよつよAndrewNg先生が共著者だったので、読んでみた
  • NGBoostは出力の不確実性を確率値として出力する
  • 自然勾配(勾配が大きく変化する場所は慎重に&勾配があまり変化しない場所は大胆に)を用いることで、最適化を効率的にしている

NLP Beginner BERTを試す

by @ktr_wtbさん

概要

  • BERTでkaggleの過去コンペを解いてみた
  • BERTなら特になにもしなくてもそこそこ良いスコアが出るかと思いきや、そんなことはなかった
  • Fine Tuningのやり方を工夫することが大事

SQLベースのMLパイプライン

by @hatuninaさん

概要

  • データセットの作成と特徴量エンジニアリングをSQLで
  • SQLをベースにすることで、使い回しやすい、共有しやすいなどのメリットがある
  • 一方で、DBが混んでいるとデータ作成がボトルネックになりがち

競艇の順位予想をしてみた

by @wakame1367さん

docs.google.com

概要

  • 競艇のデータセットは公開されているが、表データっぽいtxtデータで、データクレンジングに8割の労力を割いた
  • LightGBMでランク学習させた
  • ドメイン知識が少なく、特徴量エンジニアリングがあまりできなかった。
  • 実際に予測してみたところ、勝率は。。。

懇親会

今回はお寿司とお酒を手に乾杯しました。

参加者の方々で質問しあったり、LTの感想を伝えたりしていて、終始楽しそうな雰囲気で幕を閉じることができました!
個人的には、Twitter上で知っている人と顔を合わせてお話できたのがとても嬉しかったです!

f:id:taxa_program:20191108115122j:plainf:id:taxa_program:20191108114935p:plain

最後に

というわけで、当日の様子をお届けしました!

拙い司会・進行でしたが、最後までお付き合い頂きありがとうございました!
私自身もとても楽しく参加させていただきました!

次回開催時期・テーマなどはまだ決まっておりませんが、今回のマルシェの振り返りを社内で実施したときに「今回盛況だったから、次回も機械学習でいこうよ!(いこう)」という話がチラっとあがっていたので、もしかしたらもしかするかもしれません(笑)

参加していただいた皆さま、ありがとうございました!
また次回のマルシェでお会いできたら嬉しいです!

iOSでWebThread関連のクラッシュが急増した件

こんにちは!エンジニアの柳村です。

9月末頃からママリのiOSアプリでWebThread関連のクラッシュが増加し、ときどき爆増するといった事が起こりました。

f:id:yanamura:20191025172637p:plain

クラッシュレポートを調べてみると以下の3つクラッシュが多数発生していました。

Crashed: WebThread
0  JavaScriptCore                 0x1a583e14c WTFCrashWithInfo(int, char const*, char const*, int) + 20
1  JavaScriptCore                 0x1a5d21b3c JSC::Interpreter::prepareForRepeatCall(JSC::FunctionExecutable*, JSC::ExecState*, JSC::ProtoCallFrame*, JSC::JSFunction*, int, JSC::JSScope*, JSC::ArgList const&) + 742
2  JavaScriptCore                 0x1a5f808c0 JSC::boundFunctionConstruct(JSC::ExecState*) + 588
Crashed: WebThread
0  JavaScriptCore                 0x19407aad4 <redacted> + 20
1  JavaScriptCore                 0x1948013dc <redacted> + 746
2  JavaScriptCore                 0x194a80b50 <redacted> + 608
Crashed: WebThread
0  libGPUSupportMercury.dylib     0x1d8145fe4 gpus_ReturnNotPermittedKillClient
1  AGXGLDriver                    0x1dc7f2ed8 (シンボルが不足しています)
2  libGPUSupportMercury.dylib     0x1d8146fac gpusSubmitDataBuffers
3  AGXGLDriver                    0x1dc7f4404 (シンボルが不足しています)
4  IOAccelerator                  0x1be209884 IOAccelContextFinishResourceSysMem + 64

見ての通り、どれもなるほどわからんというエラーですね・・・

しかも、アプリやiOSのアップデートとは関係なく急増するという不思議な状況でした。

原因の分析

ママリのiOSアプリではいくつかWebViewを使っている箇所があり、どこのWebViewが原因かをまず洗い出す必要がありました。

ママリのiOSアプリではFirebase Crashlyticsを利用しており、Firebase Crashlyticsだとクラッシュレポートとログが一緒に見れるのでどの画面でクラッシュしたか判断するのに役に立ちました。

調べた結果は起動直後にクラッシュしているユーザーがいたのでトップページのどこかであるということに絞れました。

しかし、トップページにWebViewは使った心当たりはなかったので、XcodeのDebug View Hierarchy を使ってどこでWebViewが使われているか調査しました。

その結果Google Mobile AdsのDFPBannerView内でUIWebViewが使われていることがわかりました。

f:id:yanamura:20191025175922p:plain

対策

まずはSDKが古かったので最新(7.50.0)にしてみましたが効果はありませんでした。。

そこでGoogle Mobile Adsのフォーラムを見たところUIWebViewをWKWebViewに変えることができるとの情報が得られたのでやってみました。

以下のようにinfo.plistにgad_preferred_webview というKeyとwkwebview というValueを設定するとWKWebViewに変えることができました。

<key>gad_preferred_webview</key>
<string>wkwebview</string>

これをリリースしたところ、多数発生していたクラッシュがWKWebViewにしたバージョンでは発生しなくなりました!

まとめ

急にWebThread関連のエラーが増えて、Google Mobile Adsを使っている場合はinfo.plistを変更してWKWebViewに変えるとよいです。

UIWebViewはiOS13ではdeprecatedになっていますし、iOS13でUIWebViewでwindow.confirm を使うと挙動がおかしかったりするということも弊社で確認しているので、UIWebViewは捨て去ったほうがよいかと思います。

Atomic Designを実践して得た学びと失敗

🙋‍♂️エンジニアの@dachi_023です。約4ヶ月ぶりに記事を書きます、がんばります。

この記事について

コンポーネントやAtomic Designについて書いています。ここではUIデザインのフローに関するAtomic Designの実践ではなく、開発(実装)のフローにはめ込んだ場合にどうすべきなのか、というお話をしています。

コンポーネントとAtomic Design

ReactやVueをはじめとするライブラリのお陰でフロントエンド開発に「コンポーネント」という考え方が浸透した今日この頃ですが、そんなコンポーネントの設計についての話なんかをしているとよく現れるのが今回の主題に挙げている「Atomic Design」です。Atomic Designはデザインシステムを効率よく作成するための手段のひとつですが、その中に登場するコンポーネントを5階層(Atoms, Molecules, Organisms, Templates, Pages)に分類するという手法がコンポーネント指向なライブラリと相性が良く、設計や実装に取り込むことで今までよりもエンジニアとデザイナーの認識も揃えやすそうだよね〜、といった理由などにより次第にメジャーな手法となっていきました。*1

ちなみに、Atomic Designに関する解説などはしないのでよくわからないけど気になるなという方は下記のweb書籍、もしくは「Atomic Design」で検索して出てきた解説記事などを読んでいただくことをオススメします。 atomicdesign.bradfrost.com

直近1年くらいは特に「Atomic Designを参考に設計・実装しました」系の記事やスライドを見る機会も増えてきたのですが、結構ハマりどころとか似てるんじゃないかな?と思ったので溜まった学びを本記事にまとめることで誰かの役に立てれば良いなと思っています。

*1:日本だとAbamaTVさんのAtomic Design powered by React @ AbemaTVからAtomic Designが流行っていったのかな?と思っています

続きを読む

CakePHP3用のMaster/Replica接続管理プラグインをOSS化しました

こんにちは、サーバーサイドやっております 金城 (@o0h_)です。
なんとな〜〜〜くKindleのライブラリを見ていたら、スキエンティアがあって「とても美しくて良い話だなぁ。。。」と思った次第です。

スキエンティア (ビッグコミックススペシャル)

スキエンティア (ビッグコミックススペシャル)

たまに読み返したいな。

さて、掲題のとおりですが、以前にママリのマスプロモーションを実施した際の負荷対策として作成した機構をプラグインとして公開しました。
・・・という書き出しで以前に書いたのが、CakePHP2.x用のMaster/Replica接続管理プラグインです。

tech.connehito.com

それから暫く経ちましたが、この度CakePHP3用の同様のプラグインを公開しました。

packagist.org

この記事では、以下の3点について紹介したいと思います。

  1. プラグインの利用方法についての簡単な説明
  2. 設計について
  3. 「CakePHP3.xのプラグイン」を公開する際に工夫したこと

①利用方法について

CakePHP2用のプラグインと同様に、「複数の接続を管理する」「単一のモデルからそれらを任意に使い分けられる」ことを目的としています。例えば「参照しか走らないリクエストは参照用DBに接続して、更新系はマスターDBに接続する」といったような使い方を想定しています。

簡単に利用方法を紹介します。

  1. Pluginをcomposer installで導入する
  2. 「複数の接続先」をconfig(デフォルトではconfig/app.php)に書き込む
  3. (Controller等で)必要に応じて接続先情報を変更するメソッドを実行する

1. Pluginの配置

Composerによるinstallに対応しています。

composer require connehito/cakephp-master-replica

単体クラスの名前空間解決による読み込みだけで十分なので、Pluginのロード等の処理は必要としません。

2. 接続情報の設定

ConnectionManagerに喰わせる設定を変更します。
標準的な構成では、これは config/app.php にある Datasourcesの内容となります。

通常のConnectionクラス用の設定と同様に記述したあとに、「接続先の差分」を roles に書き込んでください。 共通する接続情報を記述した上で、それぞれの接続先ごとに異なる部分を記述するようになります。

例えば、以下のような3つの接続先を扱いたいという需要があったとします*1
(MySQLを使うものとします)

  1. master
    • Host: db-host
    • DB: app_db
    • Username: root
    • Password: password
  2. replica(1)
    • Host: db-host
    • DB: app_db
    • Username: read-only-user
    • Password: another-password
  3. replica(2)
    • Host: replica-host
    • DB: app_db
    • Username: read-only-user
    • Password: another-password

これに「master接続だけ利用する」場合は、CakePHP標準のConnectionを利用して以下のように記述できるかと思います。

<?php
// config/app.php
use Cake\Database\Connection;
use Cake\Database\Driver\Mysql;

return [
    'Datasources' => [
        'default' => [
                'className' => Connection::class,
                'driver' => Mysql::class,
                'persistent' => false,
                'host' => 'db-host',
                'username' => 'root',
                'password' => 'password',
                'database' => 'app_db',
                'timezone' => 'UTC',
                'flags' => [],
                'cacheMetadata' => true,
                'log' => false,
                'quoteIdentifiers' => false,
        ],
    ],
];

これを、master + replica + replica2という構成に対応できるように書き換えてみます

<?php
// config/app.php
use Cake\Database\Driver\Mysql;
use Connehito\CakephpMasterReplica\Database\Connection\MasterReplicaConnection;

return [
    'Datasources' => [
        'default' => [
                'className' => MasterReplicaConnection::class,
                'driver' => Mysql::class,
                'persistent' => false,
                'host' => 'db-host',
                'database' => 'app_db',
                'timezone' => 'UTC',
                'flags' => [],
                'cacheMetadata' => true,
                'log' => false,
                'quoteIdentifiers' => false,
                'roles' => [
                    'master' => [
                        'username' => 'root',
                        'password' => 'password',
                    ],
                    'replica' => [
                        'username' => 'read-only-user',
                        'password' => 'another-password',
                    ],
                    'replica2' => [
                        'host' => 'replica-host',
                        'username' => 'read-only-user',
                        'password' => 'another-password',
                    ],
                ],
        ],
    ],
];

このように、classNameをMasterReplicaConnectionに書き換えた上で「差分だけroles に書く」ことによって全ての接続を扱えるようになります。

3. 接続の切り替え

デフォルトでは、 master という名前の設定を用いて接続されます。
switchRole() というAPIを用いて簡単に接続先を切り替えることが可能です。

例えばTableインスタンスが手元にある場合は、Tableインスタンスを介してアクセスするのが手軽だと思います。

<?php
$this->UsersTable->getConnection()->switchRole('replica');

それ以外の場合は、ConnectionManagerを利用することになるでしょうか。

<?php
use \Cake\Datasource\ConnectionManager;

ConnectionManager::get('default')->switchRole('replica2');

比較的容易にアクセスができるので、リトライ機構の導入や局所的にアクセス先を変更したいというニーズにも対応が簡単です。

4. 発展的な利用例: CQRS的なもの

多くのWebアプリケーションで、「書き込み・更新を伴うページやエンドポイント」「参照しか用いないもの」というのが比較的はっきりと分かれるのではないでしょうか。
エンドポイント単位をいわゆるCommand/Query的に分類し、それぞれで接続先を設定できると実用できる場面が広がるように思います。

社内のプロダクトでは、Routingの設定と絡めて「どっちにつなげるか」を管理できるようにしました。 例えば「商品の個別ページ」として、 item/show というエンドポイントがあり、ここではDBの更新が走らないものとします。item/edit では情報の更新を行うため、DBの更新を行います。

まず、 routes.phpでエンドポイント個別の設定として独自のオプションであるreadOnly フラグを立てます。

<?php
//routes.php
$routes->scope('item/', ['controller' => 'Items'], function (RouteBuilder $routes) {
    $routes->connect(
        'show',
        [
            'action' => 'show',
            '_method' => 'GET',
        ]
    );
    $routes->connect(
        'edit',
        [
            'action' => 'edit',
            '_method' => 'POST',
            'readOnly' => false,
        ]
    );
});

ルーティング情報と一緒に渡ってきた内容に対して、 AppController::beforeFilter() などの「最初の方に通る共通処理」で設定を反映させます。

<?php
/**
 * routesからパラメータを読み取り、接続先のDBを切り替える
 *
 * @return void
 */
private function setDefaultDbRole()
{
    $readOnly = $this->getRequest()->getParam('readOnly', true);
    $dbRole = readOnly ? 'replica' : 'master';

    /** @var MasterReplicaConnection $connection */
    $connection = ConnectionManager::get('default');
    $connection->switchRole($dbRole);
}

これだけで、「明示的にreadOnlyフラグを折ったエンドポイント以外はレプリカを見る」機能が実現されました。

②設計について

ここからは、実装面の話を紹介させていただきます。

CakePHP3の「ORM」「DB接続」

CakePHP2と比べて3.xは「ORM周りの機能が大幅に強化・変更された」というのは主要なトピックの1つですが、ORM/Database周りに関する内部構造も複雑になっています。

主要な登場人物として「ORM」「Datasource」「Database」の3レイヤーが出てきます。
ざっとまとめると以下のようになります。

f:id:o0h:20191014023707p:plain f:id:o0h:20191014023609p:plain

通常のアプリケーション開発を進めている時に直接触るのはORM層のみで、ほぼ事足りると思います。
この記事では詳細については割愛します*2が、「Connection」と「Driver」に着目してください

Driverクラスは、ClassDocを見ると以下のようなサマリーがついています。

/**
 * Represents a database driver containing all specificities for
 * a database engine including its SQL dialect.
 */

(cakeの中では)これが最もDBに近い層で、PDOインスタンスを保持します。
Connectionクラスはこれらを使役するクラスで、Driverを生成・取得し保持します。
今回作成したかったのは「複数の接続先を管理する」機能なので、「接続を切り替える」場としてConnectionクラスを改変することにしました。

接続の生成と管理・切り替え

PHP上で実際に「DBに接続している」のは「PDOインスタンスを生成(保持)している」箇所になります。
当プラグイン = Connectionクラスでは、「クラスのインスタンス化時に、注入されている全ての設定に応じた PDOインスタンス(との仲介役であるDriverインスタンス)を生成し、保持する」という戦術を取りました。

CakePHP2用プラグインでは、Datasource\Databaseレイヤーへのハックを行いMysqlを前提としていました。そのためにPDOとも密結合になっています。
これに対してCakePHP3用のプラグインでは、接続管理が抽象化されたことで、過度な設計を必要とせずに接続用のDBドライバは付け替え可能です。その点に注目しました。

デメリットとしては、例えば「replica接続しか使わないのにmaster接続のインスタンスも生成されてしまう」といったオーバーヘッドがあります。
実際、当初は「呼び出された時点でPDOインスタンスを作り、不要になったら破棄する」という方法を実現できるか?と模索もしました。
生成自体は遅延読み込み的に生成すれば実現できそうな気はします。問題は「破棄する」タイミングです。トランザクション管理など、どうしても「DriverないしConnectionから向き合わなければいけない関心事が増える」ことで、実装上の複雑さが増しそうな懸念がありました。また、「呼び出されるたびに再接続する」ことで生じるDB接続確立は大きな負担になりそうです。

総合して、「接続するのは最初に済ませてしまう」「インスタンスを内部に保持し続ける」ことで得られる、システムリソース的にもアプリケーションコード的にも魅力を感じました。 また、これらの機能をたった70行ちょっとの単一クラスで実現できたというのは「簡潔な記述ができた」成果だとも言えるのではないでしょうか。

③「CakePHP3.xのプラグイン」を公開する際に工夫したこと

当プラグインは、元々プロダクトコードの一部として実装していたものをライブラリとして切り出したものです。
実際のプロダクトなら「コントローラーもデータベースもすべてが揃っている!」テスト環境があるのですが、スタンドアロンなライブラリでは、そうも行きません。環境構築を含む事前準備は本質的ではないストレスになると考えています。もしテストがすぐに実行できれば、どれだけ開発体験が良くなるか・・・・

この問題は個人的には毎回頭を抱える部分なので、自分なりに「こうしたら楽かな?」と思える工夫をいくつか施してみました。
なお、今もなお試行錯誤している部分なので、ぜひ皆さんのご意見も聞いてみたいです。

docker-composeの梱包

このプラグインは理屈上はDBを使わなくても実装したロジックの内容を検査が可能だと思います。しかしながら、DB周りの機能を提供するものでもあるため、テストの時点で「実際にDBに触ってみる」事ができると安心です。
そこで、docker-composeを用いてPHP+MySQLの開発土台を配布できるようにしました。
(sourceはコチラ)

これによって、例えばPhpStormユーザーであれば手軽にIDE上からのテスト実行を提供できることになります🎉

  • stormの設定
    f:id:o0h:20191014032552p:plain
    f:id:o0h:20191014032654p:plain
  • 実際にテストを実行している光景🗻
    f:id:o0h:20191014032937p:plain

(localの)テスト時にローカルからプラグインを読み込む

Composer配布前提のライブラリなので、最終的にはpackagist経由で喰わせることになります。しかし、開発中はわざわざpushするというのは面倒な話です。
そこで、 docker-composeのvolumesと(テスト実行側アプリの)composer.jsonを組み合わせることで、「テスト実行時にローカルからライブラリを読み込む」ようにしました。

ホストからDockerコンテナにライブラリのsrcを喰わせる

全体構成としては

  • src: ライブラリ本体
  • tests/test_app/composer.json: テスト実行アプリのcomposer.json
  • tests/test_app/docker-compose.yaml: テスト実行アプリのdocker-compose

となります。

docker-compose上では、次のようにして「PJ全体は /app に喰わせる」「それとは別に、 /dist 上にライブラリの本体とパッケージ情報(composer.json)を喰わせる」ようにします。

services:
  test-app:
    volumes:
      - ../../src:/dist/src
      - ../../composer.json:/dist/composer.json
      - ../..:/app
ローカルのパスをレポジトリとして設定する

composer.json上には、ローカルのパッケージを参照させるようにレポジトリ情報を追加します

"repositories": [
      {
          "type": "path",
          "url": "/dist"
      }
  ],

これで、 app/tests/test_app/vendor/connehito/cakephp-master-replica/dist を指すシンボリックになります🎉

CakePHP4を見据えて・・

次期バージョンであるCakePHP4は、すでにβ4まで進んでおり、段々と全貌が見えてきています。
CakePHP3との互換性については意識されているということで、cakephp-master-replicaプラグインにおいても可能であれば低コストに移行したいと考えています。

そこで、4.xから入る規約等への対応を実施しました。
主だったところでは以下の4点です

  1. cakephp-codesnifferを利用してPSR-12対応
  2. 厳密な型チェック(strict_types=1)
  3. 引数・戻り値の型宣言
  4. PHPStanの対応レベル引き上げ(Lv5)

strict_typesの宣言漏れについてはcodesnifferでチェックできるので、そこまでナーバスになる必要もありません(CIでコケるため)。
PHPStanのレベルについては「コーディング規約」とは異なるようにも思いますが、本体の動向に追従しようというものです。
最終的にはstableのリリースを待って移行ガイド他ドキュメントをチェックし対応することになりますが、今の時点での「変更点」としてはこんなものだと思っています。

最後に

ごく僅かなコードで機能を実現できたのは、「フレームワークに乗っかった旨味だ」と感じています!
また、実現したいコードを如何にしてフィットさせるか?という観点でのコードリーディングは、モチベーションも湧きやすく良いものです。今回の機構の開発にあたり、自分なりにCakePHP3のORM,Databaseレイヤーについて理解が深まりました。

PDOインスタンスを複数持たせるというアイディア自体についても、結果的にIlluminateの接続管理でも同様の手法を取っているものです。・・・もっとも、これは実装してから気づいたので、「もっと早く見ればよかった」と項垂れもしました。が、個人的には「悪くないやり方と思っていいのかな〜〜」と、同時に自信も深められたと言えます✨Illuminateの方が高機能な実装をしているようにも思うので、こちらもまだ改善の余地がありそうです。

今回触れた「master replica切り替え機構」の設計や詳細については、もっと詳しい資料が社内にございます🌅
コネヒトではサーバーサイドエンジニアを募集していますので、是非お気軽に遊びに来てくださいね! www.wantedly.com

また、11月に開催されるCakeFestでは弊社CTOも登壇しますので、応援してください!!

*1:実際にこんな構成が使いたいか?は別として、あくまで「こういう事ができるよ」というのを説明するための内容です

*2:手前味噌ですが、以前にこの辺りを調べてみた記事があります。よろしければ御覧ください https://cake.nichiyoubi.land/posts/10-orm-database/

AWS × slackを用いたDDL自動実行フローを構築しました

こんにちは!MLエンジニアの野澤(@takapy0210)です。

10月から軽減税率が始まりましたね。みなさんの身の回りで混乱は起きていませんでしょうか?
そんな中、軽減税率に関するこんな記事を見ました。専門家の人たちでも判断に困る事例があるようなので、難しいですね。

さて、本日はAWS × slackを使って、DDLの自動実行フローを構築した話をできればと思っています。

目次

DDLって何?

リレーショナルデータベースを対象として、テーブルなどの構造を制御することができる言語です。 「CREATE」「DROP」「ALTER」などが書いてあるアレです。

コネヒトでは、SchemafileでDBスキーマを管理することができるRidgepoleというツールを用いています。
このRidgepoleの実行環境はコンテナ化されており、AWS ECS上のサービスとして稼働しています。

従来のフロー

DBは開発環境(以下、dev環境)本番環境(以下、prd環境)に分かれており、dev環境での実行は開発者、prd環境での実行は権限のあるオペレーターに依頼して実行してもらう、というフローになっていました。

下記が詳細な手順です。

  1. local環境で開発(Schemafile)
  2. Github RepositoryにPR
  3. Githubでmaster merge(dev環境にECSデプロイが走る)
  4. 実行環境のインスタンスにSSHログイン
  5. dry-runでDDLの内容が合っているか確認(dev環境)
  6. dry-runの内容に問題がなければdev環境でridgepole(DDL)の実行
  7. 最新のコミットに対してタグをpush(prd環境にECSデプロイが走る)
  8. オペレーターに依頼し、prd環境でdry-runの実行
  9. dry-runの内容に問題がなければprd環境でridgepole(DDL)の実行

ごちゃごちゃ書きましたが、煩雑な雰囲気だけでも伝わって頂ければと思います。

今回は上記の 4, 5, 6, 8 の部分を自動化しましたので、次章以降で詳細をお伝えできればと思います。

新・自動化フロー

自動化のアーキテクチャは下記のようになっています。 dry-run実行フローとDDL実行フローの2パターンに分けて説明します。

dry-run実行

f:id:taxa_program:20191003172131p:plain
dry-run実行時

図を見ていただくと分かりやすいと思うのですが、ECRのimage更新を検知して、Step Functionisが起動し、Fargate Taskでdry-runスクリプトを実行し、結果をslackに通知してくれます。

slackへ通知するメッセージは、下記のようにdry-runの内容DDL実行の可否を問うボタンで構成されています。

f:id:taxa_program:20191003173000p:plain
dev環境のdry-run slack通知メッセージ

上記でdry-runの結果を確認し、問題なければOKボタンを押下するだけで、dev環境へのDDLが実行できます!めっちゃ便利!

ちなみに、prd環境のDDL実行はオペレーターが手動で行う運用としているため、dry-runの結果通知のみにしています。(実行時間帯や権限の関係で)

f:id:taxa_program:20191003184156p:plain
prd環境のdry-run slack通知メッセージ

次に、上記のslackメッセージでOKボタンを押下した後のDDL実行フローについてご紹介します。

DDL実行

f:id:taxa_program:20191003173408p:plain
DDL実行

slackメッセージのボタン押下イベントをAWS API Gatewayで受け取り、そこからLambda経由でStep Functionsを起動しています。
そしてFargate TaskでDDL実行スクリプトを実行し、結果をslackに通知します。

f:id:taxa_program:20191003174457p:plain
DDL実行結果のslack通知

自動化して何が嬉しかったか

DDL実行の都度、実行環境にSSH接続して、dry-runを実行して、結果を確認して、、、という手順が省略されたことが大きいと思います。

また、prd環境で実行する際は

  • オペレーターがdry-runを実行して
  • 開発者に対して、dry-runの結果に誤りがないか確認して
  • 同意がとれたら実行する

という手順を踏まなければならなかったのが、dry-runの結果は自動的にslackに通知されるので、都度開発者にdry-runの整合性を確認する必要がなくなりました。
そして、dry-run結果のメッセージに返信する形で「prd環境で実行お願いします!」と一言伝えるだけでOKになったのも、作業負荷の軽減に繋がっていると思います。

実際に、煩雑だった従来の手順が

  1. local環境で開発(Schemafile)
  2. Github RepositoryにPR
  3. Githubでmaster merge(dev環境にECSデプロイが走る)
  4. 実行環境のインスタンスにSSHログイン
  5. dry-runでDDLの内容が合っているか確認(dev環境)
  6. dry-runの内容に問題がなければdev環境でridgepole(DDL)の実行
  7. 最新のコミットに対してタグをpush(prd環境にECSデプロイが走る)
  8. オペレーターに依頼し、prd環境でdry-runの実行
  9. dry-runの内容に問題がなければprd環境でridgepole(DDL)の実行

下記のように省略されました。

  1. local環境で開発(Schemafile)
  2. Github RepositoryにPR
  3. Githubでmaster merge(dev環境にECSデプロイが走る)
  4. slackでdry-runの実行結果を確認し、メッセージ内のボタン押下でDDL実行
  5. 最新のコミットに対してタグをpush(prd環境にECSデプロイが走る)
  6. slackでdry-runの実行結果を確認し、問題が無ければオペレーターにridgepole(DDL)の実行を依頼

また、従来はEC2バックエンドだったため、常にインスタンスが起動している状態でしたが、今回はFatgate Taskで実行しているため、コストの観点からも恩恵を受けることができそうです。

アーキテクチャ構築のポイント

上記フローを構築する際の注意点をいくつかあげてみます。

Step FunctionsでFatgate Taskを実行するときの注意点

セキュリティグループを正しく指定する必要がある

Step Functionsの定義でセキュリティグループを設定しないと、デフォルトのセキュリティーグループが自動で割り当てられる(?)ようなので、想定するセキュリティーグループを指定する必要があります。

下記に例を載せておきます。

...
"States": {
    "Fargate task": {
      "Comment": "Fargate taskの実行",
      "Type": "Task",
      "Resource": "arn:aws:states:::ecs:runTask.sync",
      "Parameters": {
        "LaunchType": "FARGATE",
        "Cluster": "arn:aws:ecs:ap-northeast-1:12345678:cluster/cluster-name",
        "TaskDefinition": "arn:aws:ecs:ap-northeast-1:12345678:task-definition/task-name:1",
        "NetworkConfiguration": {
          "AwsvpcConfiguration": {
            "SecurityGroups": ["sg-id"],
            "Subnets": ["subnet-id"],
            "AssignPublicIp": "ENABLED"
          }
        }
      }
...

EcsTask実行ポリシーに、「タスクを実行するRoleにアクセスする権限」を追加する必要がある

Step Functionsに付与するIAMロールに、EcsTask実行ポリシーを追加する必要があるのですが、自動的に追加されるポリシーには、EcsTaskを実行するRoleにアクセスする権限が付与されません。(これがないとFargate Taskが実行できません)

なので、下記のようにタスクロールタスク実行ロールの2つのロールに対するアクセス権限を、Step FunctionsのIAMロールに追加する必要があります。

...
{
    "Effect": "Allow",
    "Action": [
        "iam:GetRole",
        "iam:PassRole"
    ],
    "Resource": [
        "arn:aws:iam::12345678:role/EcsTaskRoleName",
        "arn:aws:iam::12345678:role/EcsTaskExecutionRoleName"
    ]
}
...

slack apiとAWS API Gatewayの連携の注意点

ここが一番大変でした・・・
ネットにもあまり情報がないので、トライ&エラーを繰り返し、なんとか実装できました。

API Gatewayの設定

まず、AWS API GatewayでREST APIを作成します。
今回はLambdaを呼び出すので、下記のように指定します。

f:id:taxa_program:20191004172039p:plain
POSTメソッドの作成

すると下記のようなAPIが作成されます。

f:id:taxa_program:20191004172335p:plain
API作成例

次に、アクションボタンからAPIをデプロイします。

f:id:taxa_program:20191004172530p:plain:w400
APIのデプロイ

すると、下記のようなURL(エンドポイント)が取得できます。
このURLは、後述のslack APIを作成する時に必要になりますので、メモしておいてください。

f:id:taxa_program:20191004172803p:plain
API Gatewayのエンドポイント

slack APIの作成

slack APIは、slackメッセージ内のDDL実行ボタンを押下したタイミングでAPI Gatewayを呼ぶ時に必要となります。

下記に手順を示します。

1. こちらからslackAppを作成する

f:id:taxa_program:20191007103217p:plain:w400
slack Appの作成

2. Interactive Componentsの設定
AWS API Gatewayを作成したときに取得したエンドポイントを設定します

f:id:taxa_program:20191007103457p:plain:w400
Interactive Componentsの設定

3. OAuth & Permissionsの設定
まず初めに、Tokenを取得します。ここで取得したTokenは、AWS Lambda → slackに下記のようなボタン付きメッセージを投稿する際に使用します。

f:id:taxa_program:20191003173000p:plain
ボタン付きメッセージ

Tokenの取得

f:id:taxa_program:20191007104505p:plain:w500
Tokenの取得

ちなみにLambdaからは下記のようにTokenを設定してリクエストを投げます。

def sample(event, context):
    
    attachments = [{
        'text': 'dry-runの結果はいかがでしょうか? \n問題なければ「OK」ボタンを押下してDDL実行してください。',
        'callback_id': callback_id,
        'attachment_type': 'default',
        'actions': [{
            'name': 'done_yes',
            'text': 'OK',
            'type': 'button',
            "confirm": {
                "title": "Are you sure?",
                "text": "DDLを実行してもよろしいでしょうか?",
                "ok_text": "Yes",
                "dismiss_text": "No"
            }
        },
        {
            'name': 'done_no',
            'text': 'Cancel',
            'type': 'button',
            "style":"danger",
            "confirm": {
                "title": "Are you sure?",
                "text": "DDLの実行をキャンセルしてもよろしいでしょうか?",
                "ok_text": "Yes",
                "dismiss_text": "No"
            }
            
        }]
    }]

    payload = {
        'token':※ここにTokenを設定※,
        'channel': SLACK_CHANNEL,
        'username': username,
        'icon_emoji': icon_emoji,
        'attachments': json.dumps(attachments)
    }

    res = requests.post(post_url, data=payload)
    return res

最後に、然るべきPermissionを設定し、対象のチャンネルに今回作成したAppをintegrationとして追加すれば終了です!

まとめ

今回はDDL自動実行フローの構築ということで、DevOps的な取り組みについてご紹介しました。

このフローに関しては、構築に少し手間がかかりますが、一度構築してしまえばそれ以降半永久的に恩恵を受けることができます。
もし同じような悩み・課題を感じている方がいれば、一度試してみてはいかがでしょうか。

We are Hiring !

コネヒトでは、成長中のサービスを一緒に支えるために働く仲間を探しています。 少しでも興味をもたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです!

www.wantedly.com

#builderscon tokyo 2019 で当日ボランティアスタッフをしてきました

こんにちは!2019年7月にサーバーサイドエンジニアとして入社しました @takoba_ です!!

だいぶ遅くなりましたが、先月末に開催されました「builderscon tokyo 2019」に当日ボランティアスタッフとして参加してきましたので、そのレポートをします。

昨年から当日スタッフとして参加するようになりましたが、カンファレンススタッフとして参加するカンファレンスは一味違う楽しみ方ができるのでオススメです!そんな魅力が伝わるとうれしいです...!

"builderscon tokyo 2019" とは?

©️builderscon
©builderscon

buildersconでは毎年、他のカンファレンスでは聴けないようなトークが多くエントリーされています。過去にはサウンドエンジニアリングをテーマとしてセッションで、楽器(エレキギター)を持ち込んでデモを披露したスピーカーの方もいらっしゃいました...!

buildersconは、「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです

buildersconではトークに関して技術的な制約はありません。特定のプログラミング言語や技術スタックによるくくりも設けません。必要なのは技術者達に刺激を与えワクワクさせてくれるアイデアのみです。

builderscon tokyo 2019

今年は、 2019/08/29 〜 2019/08/31 の3日間、東京・北千住にある東京電機大学(東京千住キャンパス)1号館にて開催されました。立派なキャンパスだった...!

カンファレンススタッフをやると一味違う楽しみ方ができる!

カンファレンススタッフとしてカンファレンスに参加すると、参加者とはまた違った楽しみがあります。

まず、カンファレンスの裏側を気軽に覗くことができます。 自分が普段参加してるカンファレンスが「なるほど?こうやって運営されてるのね??」という部分が知れたりするのは、学びあるな〜〜〜と参加するたびに思います。
同じカンファレンスでも、以前実施した際の振り返りをもとにアップデートされている箇所があったりしますし、"ビジネス"としてのカンファレンスが垣間見えたりするのも、運営側に回ったことで得られる情報だったりするので、もし興味のある方は是非ともカンファレンススタッフをやってみてほしいと思います...!

また、一緒にスタッフをやった方々ともたくさん交流できたのは楽しかったです!スタッフとしてカンファレンスに関わっている方は、だいたい同じ属性を持っている方々なので話題も多様にありますし、終わった後にたびたび飲みに行ったのもよい思い出です。

ちなみにコネヒトでは、カンファレンス参加が業務扱いになります!!! [PR]

「カンファレンススタッフ業も業務扱いになりますか...?」と恐る恐る上長に聞いてみたら「なります!!」と二つ返事でお答えいただきました!

また、コネヒトは積極的にカンファレンスへのスポンサードもしております。当ブログにもたくさんの参加エントリがありますので、お時間ある時に見てみてください〜〜

当日スタッフはどんなことをやるのか

そんな魅了たっぷりなbuilderscon当日スタッフですが、具体的にはどんなことをやるのでしょう。その一部を、以下で簡単にご紹介します。

会場設営 / 撤収

©️builderscon
こういったホールに椅子と机を敷き詰めたりするお仕事です ©builderscon

お貸しいただいた会場を、カンファレンス実施するための状態に模様替えします。今回は広いホールを3部屋に分割するかたちで椅子や机をレイアウトしたりしてました。

また、今回は主催者の趣味によって、すっごいでかい"移動式9面サイネージパネル"が設置されました。こいつの搬入と組み立てがなかなか大変だった...。その分、完成して最初に映ったときに謎の達成感があっておもしろかったです。

各部屋の運営

©️builderscon
ホールを仕切って各部屋に変換したあとの図 ©builderscon

"部屋"とは、各種トークが開催される会場のことを指します。各部屋には、だいたい4-5名程度の担当スタッフを配置して、以下のようなことをしてました。

  • 会場設営
    • プロジェクター、タイマー、マイクetc. のセットアップ/動作確認
  • 司会/会場内アナウンス
  • マイクランナー(質問したい方へマイクを持っていく係)
  • 録画用ビデオカメラの監視
    • ブレた映像が残らないよう、人がぶつからないように注意します
  • 会場内整理
    • トークが終了するたびに参加者のみなさまの出入りが発生します
    • 部屋の動員状況によっては、心苦しいですが入場制限をしたりもしてました

ぼくは今回部屋担当になったんですが、4-5名で回していればシフトを組んで自分が観たいセッションの時には抜けられるようにすることも可能です。
(とはいえ、たまたま割り当てられた部屋が聴きたいセッションばかりで構成されてたので、ほぼほぼ自分の担当する部屋にいた気がします。)

ちなみに、初めてスタッフとして参加しても、丁寧なマニュアルが用意されていたり、"部屋番長"と呼ばれる歴戦の猛者がサポートしてくれるので安心です。

ノベルティ仕分け、配布準備

©️builderscon
ノベルティは受付でお渡ししてました! ©builderscon

来場する皆さまへお渡しするノベルティ*1が大量に届くので、それらを仕分けたり配布可能な状態にして受付に配置したりします。

昨年はチラシやパンフレットなど一部のものがバラバラに届いていたので、人海戦術でそれらを配布可能な状態にセットアップする作業が発生してましたが、今年はすでに配布可能な状態で届けられていて進化を感じました...!

おわりに

いかがでしたか?カンファレンススタッフやってみたくなりませんか???

個人的には、割と歴史が長いbuildersconのスタッフはカンファレンススタッフデビューするのにオススメだと思っています!興味のある方は、例年6月末くらいから募集し始めますので、buildersconのTwitterアカウントをフォローしてお待ちください👀

そして...ようやく...ブログを書いたので...ぼくの「builderscon tokyo 2019」が終わりを告げたぞ...!(毎度のごとく遅筆なのなんとかしたい)

*1:トートバッグ、Tシャツ、個人スポンサー向けグッズetc.

PHPカンファレンス北海道2019に協賛&参加してきました!(資料まとめ)

こんにちは!サーバーサイドエンジニアの @fortkleです!
今回は、つい先日開催された「PHPカンファレンス北海道」にCTOと2人で参加してきたのでレポートしたいと思います。

PHPカンファレンス北海道2019

2019年9月21日(土)に札幌で開催された「PHPカンファレンス北海道2019」。
前回開催が2016年だったので約3年ぶりの開催だったようです。

今回、縁あってシルバースポンサーとして協賛もさせていただきました。
コネヒトとしては、地方で開催されるカンファレンスに協賛するのはおそらく初めてで、PHPの技術コミュニティの発展に少しでも支援できたのであれば幸いです!

ちなみに、 コネヒトではメインプロダクトである「ママリ」を始めとして開発のメイン言語としてPHPを活用しており、フレームワークとしてはCakePHPを採用しています!

企業ブースとスポンサーセッション

f:id:fortkle:20190921103955j:plain
CTOと5周年記念PRキャラクター「ママリちゃん」

当日は1Fに企業ブースを出させていただきました。ブースまで来てくださった参加者の皆様、ありがとうございました!
「ママリ」は、特に男性にとってはほとんど接触機会がなく知名度も低いのですがそれでも「ママリ知ってます!」や「ペチコン東京で見ました!」というお声をちらほら頂けたのが非常に嬉しかったです!

f:id:fortkle:20190921161049j:plain
スポンサーセッション中のCTO伊藤

また、スポンサーセッションもさせていただきました。 当日のスライドも貼っておきます。

発表の中では、

  • ① なぜコネヒトはカンファレンスのスポンサーをするのか?
  • ② 技術コミュニティへの貢献を支援するための取り組み

という2点について紹介させていただきました。
2点目については、以前こちらのブログでも紹介した「ス・マイル制度」が取り組みの柱となっているのでもし興味がある方がいらっしゃいましたらご覧ください!

tech.connehito.com

当日のセッション

アンカンファレンス、懇親会LTを除くセッションについて、すでに公開されている資料をまとめてみたので参考にしてみてください! ※ 敬称略

最後に

主催の @makies さんを初めとした運営の皆様、登壇者の皆様、当日参加された皆様、本当にお疲れ様でした! 来年は通常セッションに弊社からも登壇者を出せるように頑張っていこうと思います!

余談

北海道といえばやっぱりラーメンですよね...
最高でした...

f:id:fortkle:20190920200107j:plain

味噌ラーメンも...

f:id:fortkle:20190922121030j:plain

カンファレンス終了後の懇親会では豪華な料理が振る舞われていました...

f:id:fortkle:20190921190119j:plain

北海道最高!!!また行きます!