こんにちは。品質管理部エンジニアリングチームの遠藤です。 前回の壮絶な失敗を何事もなかったかのように忘れ去り、次のテーマへ移りたいと思います。 工夫しなければいけなかったこと ZOZOSUIT自動測定については前回のとおり何となくぼんやりとイメージはついていたのですが、「これはどうしよう」と思ったことが2つありました。 デバイスIDに依存したくない 外部ディスプレイにどうやってブラウザ開くの？ といったことでした。 Androidデバイスの制御をする場合、デバイスIDをもとに制御するわけですが、これをそのままプログラム内に書いてしまうとその端末しか制御できません。またディスプレイが複数ついているためどのディスプレイにどの端末を向けているのかを事前に登録してからプログラムを動作させなければいけません。最初はとりあえずプロトタイプということでそのまま動かしていましたが、まずはここをなんとかしたかったです。 とりあえず、やってみます。 私やる！やるったらやる！ では具体的にどうすればよいでしょうか。デバイスに接続しているUSBケーブルの情報から接続しているデバイスIDがわかればなんとかなりそうです。とりあえず何も接続しない状態で、USBのシステム情報を確認してみます。 % ioreg -p IOUSB -w0 +-o Root <class IORegistryEntry, id 0x100000100, retain 15> +-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x100000351, registered, matched, active, busy 0 (0 ms), retain 15> +-o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x100000fc5, registered, matched, active, busy 0 (9 ms), retain 33> こんどはUSBポートを増設した状態でやってみます。 % ioreg -p IOUSB -w0 +-o Root <class IORegistryEntry, id 0x100000100, retain 15> +-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x100000351, registered, matched, active, busy 0 (0 ms), retain 17> +-o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x100000fc5, registered, matched, active, busy 0 (9 ms), retain 33> +-o 4-Port USB 2.0 Hub@14100000 <class AppleUSBDevice, id 0x1000022ba, registered, matched, active, busy 0 (2 ms), retain 21> +-o 4-Port USB 3.0 Hub@14400000 <class AppleUSBDevice, id 0x1000022d0, registered, matched, active, busy 0 (1 ms), retain 21> ポートが認識されています。そこにデバイスを接続してみます。 % ioreg -p IOUSB -w0 +-o Root <class IORegistryEntry, id 0x100000100, retain 15> +-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x100000351, registered, matched, active, busy 0 (0 ms), retain 17> +-o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x100000fc5, registered, matched, active, busy 0 (9 ms), retain 33> +-o 4-Port USB 2.0 Hub@14100000 <class AppleUSBDevice, id 0x1000022ba, registered, matched, active, busy 0 (2 ms), retain 22> | +-o F5321@14110000 <class AppleUSBDevice, id 0x100002315, registered, matched, active, busy 0 (7 ms), retain 25> +-o 4-Port USB 3.0 Hub@14400000 <class AppleUSBDevice, id 0x1000022d0, registered, matched, active, busy 0 (1 ms), retain 21> 14110000にF5321が接続されています。いろいろ抜き差しして調査してみた結果、この番号は基本的に変わらないようでした。 自分の環境ではこんな感じでした。このナンバーのケーブルをあらかじめ対応させる予定の外部ディスプレイに向けておけばいい感じにいけそうです。 で、さっきのコマンドでデバイスIDを確認してっと、 これよく見たらデバイスIDじゃなくてデバイス名じゃねーか！ adb devices でデバイス名との対応ができればいいのですが、表示されません。 と思ってたら　 adb devices -l で表示されました。 最初（さっきまで）はこれを知らず、 system_profiler SPUSBDataType から無理やり取得していました。 コードに置き換えてみる（python3） では早速これをコードに置き換えてみます。 import subprocess def cmd (_cmd_str): # print("cmd:" + _cmd_str) proc = subprocess.run(_cmd_str, stdout=subprocess.PIPE, shell= True ) return proc.stdout.decode( "utf8" ) #指定したUSB IDに繋がっているAndroidデバイス名を取得する def check_usb_connect (_check_usb_id): cmd_str = "ioreg -p IOUSB -w0 | sed 's/[^o]*o //; s/ <.*$//' | grep '.*@.*' | grep -v Hub | grep -v USB" res = cmd(cmd_str) # print(res) for line in res.splitlines(): dn, usb_id = line.split( '@' ) # print(dn, usb_id) if usb_id == _check_usb_id: return dn return "" #デバイス名からデバイスIDを取得する。 def deviceId_from_deviceName (_deviceName): cmd_str = "adb devices -l" res = cmd(cmd_str) for line in res.splitlines(): if "product:" in line: device_id, etc = line.split( ' ' ) elist = etc.split( ' ' ) # print(device_id) device_name = elist[ 4 ].split( ':' )[ 1 ] if device_name == _deviceName: return device_id return "" print ( "-----------" ) device_name = check_usb_connect( "14110000" ) print ( "device_name:" + device_name) device_id = deviceId_from_deviceName(device_name) print ( "device_id:" + device_id) できました！ 注意点 ただ、これだと同じデバイス名の端末を接続すると見分けがつきません。なので system_profiler SPUSBDataType などの情報から、USBポートとの対応など考慮してデバイスIDを取得したほうがよさそうです。 次回予告 幾夜魘されたか知らない悪夢、目の前の僅かな一跨ぎ。それができない泥沼の中で 俺は喘ぐ。 俺はどうしようもない絶望の中、次のミッションに取り掛かった。 今回はうまく行ったが次の問題がうまく行くと保証されたわけじゃない。 だが前に進まねばならない。俺が俺でいるために。 人を人たらしめるもの、それが目の前の問題をただがむしゃらに考え生きる、 ということなのだとするならば、あるいは俺も・・・。 そんなことを考えながら、俺は目を閉じ、今日も水玉のスーツに袖を通す。 次回、最終章（発動編）。ブラウザの扉は開くのか？ 最後に ZOZOテクノロジーズでは、一緒にサービスを作成、サポートしてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ www.wantedly.com

こんにちは。開発部に所属している鶴見です。 弊社ではAzure SQLDatabaseを利用して運用している箇所があります。 SQLDatabaseのデータ検索に利用している列ストアインデックスについて紹介します。 はじめに Azure SQLDatabaseはMicrosoft社が提供しているマネージドデータベースであり、SQL Serverエンジンと互換性があります。 ZOZOTOWNで扱っている大量データの中から対象データをピンポイントに探す場合は、SQLDatabaseのB-treeインデックスを利用し高速に検索しています。 しかし、B-treeインデックスは広範囲の検索が苦手という弱点があります。 そこで、広範囲の検索をする場合は、列ストアインデックスを利用してみました。 主にデータウェアハウスやデータ分析にて利用されていますが、 ここ数年の進化によりOLTPでも利用しやすいインデックスとなりました。 列ストアインデックスとは 広範囲の検索で性能向上が見込める列指向型インデックスです。 B-treeインデックスが行単位でデータを扱うのに対して、列ストアインデックスは列単位でデータを扱います。 列ストアインデックスとB-treeインデックスの比較です。 インデックス種類 B-treeインデックス 列ストアインデックス 指向性 行指向 列指向 読込 ページ単位（1ページ8kb） セグメント単位（1セグメント約100万件） 圧縮 可 可 scan操作 可 可 seek操作 可 不可 単一行検索 得意 苦手 広範囲検索 苦手 得意 B-treeインデックスで1カラム100万件のデータ取得を行うと大量のデータページを読込みます。 対して、列ストアインデックスは1カラム100万件を1セグメントとしているため、1回の読込みで済みます。 また、列単位で圧縮されるため圧縮率が高く非圧縮データ サイズと比較して、最大10倍のデータ圧縮が見込めます。 列単位で管理されることによりB-treeインデックスのように指定するカラムの順番を気にする必要もありません。 よって大量データを集計する処理などデータ分析に向いています。 SQL Server2012で登場した当初は「行データの更新・削除・挿入は行えない」などの制限があり、 常にデータ更新のあるデータベースでは利用しにくい状況でした。 しかし、SQL Server2014～2017にかけて制限が緩和され、データ更新に対応しました。 SQLDatabaseで列ストアインデックスを利用できるモデルは次の通りです。 Premiumレベル Standard S3レベル以上 General Purposeレベル Business Criticalレベル 列ストアインデックス作成 次の構文にて列ストアインデックスを作成可能です。 CREATE NONCLUSTERED COLUMNSTORE INDEX [index_name] ON [table_name] ( [column_1], [column_2], [column_3] ) 性能検証 実際にテストデータで性能を検証してみます。 テストテーブルに1億件のデータを登録し、そのうち1千万件データを取得した場合のB-treeインデックスと列ストアインデックスの処理能力を検証します。 -- テストテーブル CREATE TABLE test ( id int NOT NULL , age int NOT NULL , name nvarchar( 100 ) null CONSTRAINT primary_key_test PRIMARY KEY CLUSTERED ( id ASC ) 1億件のテストデータを登録した後、 カラム[age]に対してB-treeインデックス、列ストアインデックスをそれぞれ作成します。 -- B-treeインデックス作成 CREATE NONCLUSTERED INDEX [NONCLUSTERED_INDEX] ON [dbo].[test] ([age]) GO -- 列ストアインデックス作成 CREATE NONCLUSTERED COLUMNSTORE INDEX [COLUMNSTORE_INDEX_test] ON [dbo].test ([age]) GO 検証のため各インデックスが利用されるようヒント句でインデックスを固定しクエリを発行します。 （テストデータ1億件のうち、age = 21が1000万件となるようにデータを作成しています） -- 1000万件取得クエリ B-treeインデックス使用 select count(*) From test with ( index (NONCLUSTERED_INDEX)) where age = 21 -- 1000万件取得クエリ 列ストアインデックス使用 select count(*) From test with ( index (COLUMNSTORE_INDEX_test)) where age = 21 検証結果 検証結果は次の通りです。 B-treeインデックス（非クラスター化インデックス）を利用した場合。 実行プラン / 実行時間 列ストアインデックス（非クラスター化列ストアインデックス）を利用した場合。 実行プラン / 実行時間 列ストアインデックスが利用されていることが確認できる。 クエリにてCOUNTを行ったためハッシュ ベースの集計関数が利用されHash Match操作となった。 並列実行のためParallelism操作となった。 インデックス種類 CPU time elapsed time B-treeインデックス 2220ms 1647ms 列ストアインデックス 46ms 8ms CPU time及び、elapsed time（経過時間）の結果から、列ストアインデックスを利用した方が高速でした。 処理時間が「CPU time > elapsed time」となっているのは、並列で処理されているためです。 実行プラン詳細にて、論理操作はインデックススキャンであることが確認できます。 これは列単位で全件スキャンを行っているためです。 また、列ストアインデックスを利用すると実行モードはBatchとなります。 気を付けたいポイント 一見良さそうな列ストアインデックスですが、メンテナンスを怠ると性能が低下します。 列ストアインデックスに含まれる列データが大量に更新された場合、更新データは非圧縮状態になります。 圧縮されていることで最適なパフォーマンスとなるため、非圧縮データが増えてしまうと読込むデータが増え性能低下します。 列ストアインデックス状態確認 次のクエリで列ストアインデックスの圧縮状況を確認できます。 -- 列グループ状態確認 select OBJECT_NAME(object_id) AS object_name ,* from sys.column_store_row_groups total_rowsの値を確認すると、約100万件の単位でグループ化されていることが分かります。 state_descriptionの値がCOMPRESSEDの場合はデータ圧縮されており最適な状態です。 データ更新されるとstate_descriptionの値がOPENに変わり非圧縮状態となります。 OPENの件数が増えた場合は、インデックス再構成を実行して圧縮状態に戻すことができます。 インデックス再構成はオンラインで実行可能です。 更新が多いテーブルで列ストアインデックスを利用する場合、どのようなタイミングでインデックス再構成を行うか考える必要があります。 実際に利用する場合は、よく検証してから利用することをお勧めします。 まとめ 狭域の検索はB-treeを利用し、広範囲の検索は列ストアインデックスに置き換えました。 これにより、どのような検索であっても高速に処理することが可能となりました。 B-treeインデックスに比べると、考慮すべきことが多い列ストアインデックスですが、使いどころによってはかなり有効かと考えます。 参考文献 列ストア インデックス: 概要 | Microsoft Docs 最後に 本文でも紹介しましたが、本システムにはまだまだ問題が残されています。弊社では一緒にデータ基盤を作ってくれる方を大募集しています。 ご興味がある方は以下のリンクから是非ご応募ください！ www.wantedly.com

こんにちは、サーバーサイドエンジニアの竹若です。11/13 ~ 11/15にかけてロサンゼルスで開催された RubyConf2018 にZOZOテクノロジーズから竹若・高木( @rllllho )・田島( @katsuyan121 )の3人が参加しました。 今年のRubyConfは講演数60、参加者数840の大規模なカンファレンスでした。この記事では私たちが興味を持った講演をいくつか紹介させていただきます。 Opening Keynote Sweat the Small Stuff Being Good: An Introduction to Robo- and Machine Ethics Empowering Early-Career Developers Ethical Data Collection for Regular Developers The Ruby Developer's Command Line Toolkit Pointers for Eliminating Heaps of Memory Parallel programming in Ruby 3 with Guild Building Serverless Ruby Bots Runnning a Government Department on Ruby for over 13 Years It's Down! Simulating Incidents in Production Yes, You Should Provide a Client Library For Your API Unlearning: The Challenge of Change まとめ Opening Keynote Opening Keynoteは、Rubyのパパであり弊社ZOZOテクノロジーズの技術顧問でもあるMatzさんの発表です。 コミュニティの力や、Rubyのこれからについて話されていました。 プログラミング言語は人間によって作られたものであり、C言語はOSを書くためHaskellは教育のためなどそれぞれの言語が作られた背景には明確な目的や意図があります。 RubyはMatzさんのアイデアを表現するために開発されたそうです。 Matzさんが自分のために作り始めたRubyが世界中で使われるようにまでなった理由として、Rubyコミュニティの力があるそうです。 OSSコミュニティは人の集まりではなくバーチャルなようなものです。 コミュニティは例えるなら台風で、目には見えないがとても巨大なものであるとおっしゃられていました。 またRubyコミュニティは誰か個人のものではなく、Matzさん自身もコミュニティの一部に過ぎないとおっしゃられていました。 OSSコミュニティは知的好奇心、コミュニケーション、責任の3つが大事で、Rubyはこれらを持ったとてもよいコミュニティであるとおっしゃられていました。 "Ruby is dead" という意見を聞くことがあります。 ハイプ・サイクルをもとに考えるとRubyは『Trough of Disillusionment(幻滅期)』のフェーズに位置しており、今こそRubyへ新しい投資ができるフェーズで積極的にRubyを使って欲しいとおっしゃっていました。 近年開発されたSwiftやGoなどのプログラミング言語は会社が開発したものですが、Rubyはコミュニティによって開発されています。 これからRubyが生き続けるために、 Never give up Keep moving Community Be nice Be happy であることが大事であるとお話しされていました。 Rubyのこれからの改善については、2018年12月にRuby2.6がリリースされ2020年にRuby3、2025年ごろにはRuby4の開発もありうるかもしれないとお話しされていました。 発表を聞き改めてコミュニティの大事さと自分もRubyコミュニティに貢献していきたいと思いました。 RubyConfはとても初めての参加者が多く、このような間口の広さもRubyコミュニティのいいところだと思います。 Matzさんが2025年には60歳になるとのことで、Rubyの言語デザインについてはどのように引き継がれていくのかについて気になりました。MatzさんのAI化も本当にありうるかもしれません。 これからのRubyも楽しみです。 Sweat the Small Stuff Aaron Harpoleさんによる、組織をスケールさせる際によく見られるアンチパターンとその対処法を紹介する講演でした。 「チームが小さかった頃は全員がプロダクトを熟知していて、ミーティングもなく、デプロイとフィードバックのサイクルを小さく収めることができていた。しかしチームが大きくなるに従い既存のやり方が通用しなくなりチームの歯車がうまく回らなくなっていった」 といった事態に陥らないためのTIPSが紹介されていました。 具体的には以下のような内容でした。 エンジニアが生産性を高めるための投資を惜しまない（CIサービス、マシンのスペック） トライ＆エラーがしやすい開発環境を用意してデプロイを安全にする ミーティング前に各々が論点を紙にまとめておいてミーティングの最初に読み合う エンジニアの採用ではまず最初にエンジニアが採用候補にコンタクトする またチームの既存文化を変えることの難しさを説き、リクルーティングは文化を構築する最大のチャンスであると述べていました。 私が所属しているチームもまだ編成されて日が浅いのですが、今回のAaronさんの講演は今後チームをスケールさせていく上で気を配っておくべきポイントを明確化するのに役立つと思いました。 参考 : https://icanthascheezburger.com/wordpress/?page_id=222 Being Good: An Introduction to Robo- and Machine Ethics Eric Weinsteinさんによる、技術者が持つべき倫理と人工知能が持つべき倫理に関する講演でした。 技術者が持つべき倫理のお話ではソフトウェアのバグが原因で複数の死者を出した放射線療法機器「セラック25」やシステムの脆弱性をハックされ巨額のお金が不正送金されたブロックチェインを使ったプロジェクト「The DAO」を引き合いに出しながら以下のことを述べていました。 医療と同じで技術も技術者が標準治療を遵守しなければ人命を危険にさらしてしまうこと システムの要件を満たすのに十分に強力であると同時に必要以上に強力ではない、必要最低限の力を持ったプログラムを書くことが必要であること 人工知能が持つべき倫理のお話ではFace IDや自動運転技術を例に出して以下のことを述べていました。 人工知能に「決定」や「認識」などの人間的な行いをさせるということは暗黙的に人工知能の行動に倫理的な重みを持たせているということ 人工知能の行動に対する説明とその責任を取ること 今後技術が発展し今まで人間のやってきた仕事が機械に置き換えられていくに従い、機械の保つべき倫理の水準などの議論が更に増すはずです。 技術者の関心は何かと技術そのものだけに集中してしまう傾向にあります。しかしそれにまつわる倫理や付随する責任を考慮して初めて世に役立つものが生まれると思います。 今回のEricさんの講演の内容には今後技術と倫理に関する議論をするために必ず認識しておかなければならない重要な事実が詰まっていると感じました。 Empowering Early-Career Developers Mercedes Bernardさんによる、自身の経験に基づいた経験の浅いエンジニアをベテランエンジニアにまで育てるためのアプローチを紹介する講演でした。 Mercedesさんのチームでは経験の浅いエンジニアを育てるためにキャリアの早い段階で色々な裁量を与えているそうです。 経験の浅いエンジニアがいきなりベテランエンジニアの仕事を振られて困らないように早めに経験を積ませてあげることが重要であるとおっしゃっていました。 Mercedesさんはコンサルタントのチームを率いているそうで、具体的な内容はエンジニアに当てはまるものではありませんでした。しかし経験の浅いエンジニアをベテランエンジニアにするためのアプローチは、フレームワークとしては有用な気がします。 個人的にはメンバーそれぞれが優秀で頼りあうことのできるチームが理想です。チームの他のメンバーをレベルアップするアプローチを紹介する今回のMercedesさんの講演は非常に興味深かったです。 参考 : http://downloads.ctfassets.net/kueynwv98jit/2Dmircv1tmgoSAkc6UKggO/2120031f5d7f810ab6a13edae3642fe5/EmpowerEarlyCareerDevs.pdf Ethical Data Collection for Regular Developers Colin Flemingさんによる、自身の経験を基にした機密性の極めて高いデータを扱う際の倫理についての講演でした。 昨今の巨大テックカンパニーのデータの扱いをみて、データの扱いにもACM Code of Ethicsのようなベストプラクティスが必要になっているとのことでした。 ACM Code of Ethicsとはコンピューターのプロフェッショナルが倫理的な決断を下すのを助けるためのガイドラインです。 ColinさんはこのACM Code of Ethicsをシンプルに3つのポイントに要約していました。 Everyone is a stakeholder in computing Avoid harm and protect privacy avoid yolo-driven development あくまで倫理に関する講演だったのでデータの収集、セキュリティなどの技術的なお話はありませんでした。 今回のColinさんの講演は中絶に関するデータという非常に機密性の高いデータを扱っているところに興味を惹かれたので、この講演を1日目で一番楽しみにしていました。 機密性の高いデータをクライアントから集める時にもう一度聞き返したくなるような内容でとても勉強になりました。 The Ruby Developer's Command Line Toolkit Brad Uraniさんによる、生産性を上げるツールの数々を紹介する講演でした。 dotfiles zsh tmux fzf のような多くの開発者の支持を得ている便利ツールが中心に紹介されていました。 他にはhomesickやgit/hooksでcommitの前に何かを仕込むTIPSであったり、gemrcやrailsrcを使って開発を少し便利にするTIPSの紹介もありました。 またQ&Aでは質問者が便利だと思うツールが挙がったりして、moshなどのツールが紹介されていました。 中心的に紹介されていたツールはどれも素晴らしく便利なものばかりで、開発を始めたばかりの人なら誰にでも聞く価値のある講演でした。 私も開発を始めた頃にこれらの便利ツールを知っていたら生産性が上がって幸せになっていただろうなぁと思います。 もし今回のBradさんの講演で紹介されていたツールの中に試したことのないツールがあればぜひ試して見ることをお勧めします。 使ったことのないツールが自分の作業効率にどれだけ貢献してくれるかは使ってみなければわからないので、すぐに試してみるのがよいと思います。 私もhomesickやfzfを試してみたいと思います。 参考 : https://docs.google.com/presentation/d/18LyKvXRYZZA1RuPsZ4MvwKlufMhXDhWIM15LmK3oQ8A/edit#slide=id.p Pointers for Eliminating Heaps of Memory MRI、RailsのコアコミッターであるAaron Pattersonさんによる、Rubyのメモリ消費量を削減する2つのパッチを紹介する講演でした。 1つ目のパッチは require のメモリ消費量を削減するものでした。 このパッチを理解するのに前提知識として必要なのがShared Stringという概念です。 これはRubyの文字列オブジェクト（RString）が同じ文字列を共有することなのですが、1つ注意点があります。 それはRubyの文字列オブジェクト（RString）が参照する文字列が最後の文字まで等しくないと、同じ文字列が共有されないということです。 例えば /a/b/c.rb と /b/c.rb の文字列オブジェクトは /a/b/c.rb という文字列を共有しますが a/b/c.rb と a/b/c の文字列オブジェクトは文字列を共有せず、それぞれ a/b/c.rb と a/b/c という別の文字列を参照します。 require '/a/b/c.rb とすると loaded_fatures_index というハッシュに以下のような8つの文字列がキャッシュされます。 '/a/b/c.rb', '/a/b/c', 'a/b/c.rb', 'a/b/c', 'b/c.rb', 'b/c', 'c.rb', 'c' 接尾辞に .rb とつく文字列オブジェクトは /a/b/c.rb という文字列を共有するのですが、接尾辞に .rb がない文字列オブジェクトはそれぞれ別の文字列（ /a/b/c , a/b/c , b/c , c ）を参照するようになっています。 今回そこで接尾辞に .rb とつかない文字列オブジェクトが全て /a/b/c という文字列を参照するようにすることで同じ文字列を共有できるようにしたそうです。 結果シンプルなRailsアプリケーションの起動時のメモリ消費量を4.2％削減することに成功したそうです。 2つ目のパッチはISeqオブジェクトから文字列を直接参照することでメモリ消費量を削減するものでした。 ISeqオブジェクトとは、Rubyのコードをコンパイルすると生成されるオブジェクトです。 そしてこのISeqオブジェクトの中にバイトコードが格納されます。 ここで登場するのが mark array というオブジェクトがGCに消されないようにオブジェクトをマークするのに使われる配列です。 今まではISeqオブジェクトはこの mark array を通してオブジェクトを参照していました。 そこでこのパッチでISeqオブジェクトから直接オブジェクトを参照するようにしたようです。 結果Railsプロセスのメモリ消費量を6％削減することに成功したそうです。 今回のAaronさんの講演はRubyの内部をわかりやすく紹介する内容にもなっていてとても面白かったです。 またAaronさんはハンバーガーの帽子をかぶって登場し、GithubがMicrosoftに買収されたことにかけたダジャレを連発したりしてとてもユーモアがあって素敵でした。 Parallel programming in Ruby 3 with Guild Koichi SasadaさんによるGuildを使った並列処理の講演でした。 GuildとはRuby 3で導入予定の新しい並列処理です。 1つのGuildは1つ以上のスレッドを含み以下のような構成になっているそうです。 異なるGuildに入っているスレッドは並列処理できる 同じGuildに入っているスレッドは並列処理できない またGuild間では共有できるオブジェクトが決まっており、Guildを使うことでスレッドセーフな処理を簡単に書くことができるとのことでした。 Guild間で共有できるオブジェクトには以下が挙げられていました。 イミュータブルなオブジェクト（fronzeしたオブジェクトはそのオブジェクトに含まれるオブジェクトもすべてfrozenされている必要がある） Class/Moduleオブジェクト Isolated Proc また、共有できるオブジェクトについては特別なプロトコルを設けたいとも話していました。 案としては紹介されていたものは、GuildからGuildへのオブジェクトの受け渡しです。 Guildから他のGuildへオブジェクトを渡し、元のGuild内からは渡したオブジェクトが参照できなくなると言ったアクターモデル。 または、Goのchannelのような特別なオブジェクトを利用したCSPモデルが案として紹介されていました。 またこのGuildという名前はまだ決定しておらず code name だそうです。 デモではフィボナッチ数列を40vCPUの上で40個のGuildを使って並列処理した結果とシリアル処理した結果の比較を見ることができました。 n = 30の時点で実行時間に約16.2倍の差が出ていました。 今回のSasadaさんの講演ではGuildの実装ステータスなどのお話もあり、Guildに関する色々な情報を知ることができてとても面白かったです。 Ruby 3でGuildを使った並列処理を書くのが楽しみで仕方がないです。 参考 : http://www.atdot.net/~ko1/activities/2018_rubyconf2018.pdf Building Serverless Ruby Bots NetflixのDamir SvrtanさんによるServerlessをRubyで実現するお話でした。 AWS Lambda上でRubyを動かす話が中心に行われました。 現在AWS LambdaはRubyに対応しておらず、直接RubyをLambda上で動かすことができません。 そこで、 Traveling Ruby ・ mruby ・ jruby の3つRuby処理系を利用しRubyをLambdaで実行可能にする方法が紹介されました。 Traveling Ruby、mrubyの場合はjsにコンパイルを行い、jrubyはjarにコンパイルしLambda上でRubyの実行を実現していました。 それぞれの処理系のコードサイズ、メモリ使用量、実行時間についての比較が行われていました。 処理系 コードサイズ メモリサイズ 処理時間 ウォームアップ後の処理時間 Traveling Ruby 6.7MB 25MB 3900ms 3300ms mruby 945KB 40MB 3900ms 3300ms jruby 23.2MB 150MB 25000ms 1200ms やはりLambdaのコールドスタートの影響で、jvmの起動に時間がかかると示されました。 ただしウォームアップされた状態だとjrubyの処理時間がダントツで早くなったそうです。 AWS Lambda以外でのServerlessについてもお話され、IBMクラウドのサーバレスのシステムがRubyに対応していることが紹介されました。 また、Rubyに対応したServerlessフレームワークServerless/FaaStRubyが紹介されました。 AWSLambdaでRubyを利用するには、まだまだ必要であり早く公式対応をしないかなと思いました。 3つの処理系でのメトリクスの比較はウォームアップ後にjrubyでの実行が高速になることなど、Lambdaやjvmの特性に合わせて計測を行っており参考になるなと感じました。 また知らないクラウド技術やフレームワークが紹介されておりとても興味深かったです。 Runnning a Government Department on Ruby for over 13 Years Jeremy Evans( @jeremyevans0 )さんによる California State Auditor という政府組織のレガシーなシステムをRubyを利用してモダナイズしているというお話でした。 もともとのシステムはすごくレガシーな状態でRubyを利用してモダナイズしているそうです。 モダナイズにRubyを選んだ理由としては以下の4つ挙げていました。 高速に開発が可能 簡単にモダンなアプローチを採用できる 容易に学習が可能 楽しい 高速開発、並びにモダンなアプローチは様々なOSSを駆使することが可能で、Rubyには豊富なOSSライブラリが揃っています。 また、政府組織のシステムということもあって採用の問題があると語っていました。そのため、学習が容易であるRubyを利用することで、誰でも開発に参加できます。 また、スピーカーの方は Roda というルーティングライブラリ。 Sequel というDBライブラリを作成しており、California State Auditorのシステムで利用しています。 Railsを利用せずにCodaやSequleを開発している理由としては、モダナイズのプロジェクトを進めるにあたり、スタートは小さくシンプルにしたかったとのことでした。 利用している技術スタックがFreeBSD/PostgreSQL/nginx/Unicornと私達にとってすごく身近なものでした。 勝手な思い込みですが政府のシステムでRubyが使われているとは思っていなかったのですごく興味深かったです。 参考 : https://code.jeremyevans.net/presentations/rubyconf2018/index.html It's Down! Simulating Incidents in Production Kelsey PedersenさんによるStitch Fixで実際に行っているインシデント発生時のシミュレーションやカオスエンジニアリングについてのお話でした。 インシデント発生シミュレーションは9つのステージにそって行われます。Stich Fixではシミュレーションの当日をGameDayと呼んでいるそうです。 1.　Define simulation まずはじめに、どのインシデントを対象にしたシミュレーションを行うのかを決定します。インシデントはデータベース障害・インスタンス障害・外部サービスの障害など様々な障害が原因で発生します。 発表ではサービス障害インシデントのシミュレーションを選択し、サービスが500エラーを返した場合についてシミュレーションされていました。 2.　Implementation 1で設定したインシデントが発生するように実装を行います。 今回のケースではHTTPクライアントライブラリの Faraday にシミュレーション用の実装をしていました。 まず、インシデントを発生させるためのユーザーを作成します。そして、対象ユーザーの場合のみFaradayが常に500を返すようにoverwriteしていました。 3.　Gather expectations チーム内で、対象のインシデントがサービスにどのような影響が出るのか議論を行います。 実際に行なった議論では、動かなくなる部分は発生するがクリティカルな問題は発生しないという意見が7割であったそうです。 4.　Huddle as a team テーム全員が集合します。インシデントを想定して各人がリモートでビデオチャットを利用し議論している様子が見られました。 5.　Talk through expectaion インシデントに対してどのようなことが起こるのか議論し、洗い出しを行います。それを以下の2点の観点からまとめを行っていました。 bullet point list of expectations list the set of instructions 6.　Run it! 以下のようなコマンドで、準備したインシデントを発生させます。 bundle exec rake gameday:start そして、実際に何が起こるのかをサービスのページ・サービスのメトリクスを見て確認します。 最後に以下のコマンドで、GameDayを終了します。 bundle exec rake gameday:end 7.　Revisit expectation 事前に想定していたインシデントと比べ、実際におきたインシデントがどう違ったかを振り返ります。 8.　Write and edit runbooks インシデントが起こった時にどのような対応を行ったかをゲーム実施前のドキュメントに追加します。 9.　Update dashboards エラー監視ツールのダッシュボードなどにGameDayなどタグ付をし、エラーメトリクスがGameDayのものであることを判別できるようにします。 実際のインシデントに対してシミュレーションを行っておくことで、いざそのような状況が発生した場合に焦らず対応ができるようになるだろうなと思いました。 さらにインシデントが発生した場合に起こる問題を事前に対策できるなと考えました。 シミュレーションを行う環境を整えることは大変なことですが、安全で柔軟なシステム運用を行うにあたりとても大切なことであると実感しました。 弊社でもこの発表を参考にインシデントに対するシミュレーションを行なってみたいと思いました。 Yes, You Should Provide a Client Library For Your API Daniel Azumaさんによる、APIのクライアントライブラリについての話でした。 Danielさんは、Google Cloud Platform(GCP)のRubyAPIクライアント開発者の方です。 Googleでは膨大な数のAPIとAPIのクライアントライブラリを提供しています。 それらをメンテナンスし続けるにあたり、APIクライアントライブラリを開発する際に気をつけるべき点についてお話しされていました。 具体的にはAPIクライアントライブラリ内で以下の4つのことを意識することが大事とのことでした。 独自で処理をラップしたクラスなどを作らずRubyの記法をつかって開発を行う エラーハンドリングを適切に行う セキュリティを担保する パフォーマンスを意識する パフォーマンスを意識するという話の中で、ログの書き込み処理などについてはユーザーからのリクエストを同期的に処理せず、非同期にバルク処理を行うことでパフォーマンスを向上させていると話されておりとても参考になりました。 またOpenAPIのようなインタフェース記述言語を使用し、コードジェネレータを用いてAPI定義書からAPIクライアントライブラリのインタフェースを生成することを推奨されていました。 API定義書からコードジェネレータを用いることで、APIクライアントライブラリのインタフェース以外にも リファレンスのドキュメント サーバーのスケルトン テスト などを生成することもできるため、API開発と保守の双方の役に立つということでした。 この発表を聞き、REST APIの開発はSwaggerなどのAPI定義書からAPIのインタフェースやドキュメント、テストはコードジェネレータで生成するという開発の流れがよさそうだと思いました。 発表スライドがとてもわかりやすいので、興味のある方はぜひご参考ください。 弊社でも以前、SwaggerからAPIのシリアライザーを生成するgemを開発した記事を公開しているのでこちらも参考にしてください。 techblog.zozo.com Unlearning: The Challenge of Change RubyConfでは、女性の参加者・登壇者の多さがとても印象的でした。 カンファレンス自体とても初心者歓迎の空気を感じましたし、Rubyの話だけでなく開発手法やエンジニアとしての働き方などの話もあり女性の方も参加しやすいのかなと感じました。 また3日間の最初のKeynoteの登壇者が、Matzさん以外女性であったこともとても印象的でした。 3日目のKeynoteはJessie ShternshusさんのUnlearningについてのお話でした。 Unlearningとは今まで学んだ知識や自分が持っている価値観を意識的に捨て、新たに学び直すことを意味するそうです。 新しい知識やスキルを身につける際、既存の知識があると既存の知識や習慣に頼ってしまいがちです。 しかし未学習の場合は外部から様々な学習法を探し取り入れようとします。そのため組織やチームで、新しいことを身につけたり変化を起こそうとする時に、すでに知識を身につけていることが足枷になることがあります。 そのためunlearningnの重要性についてお話しされていました。 一度自分がもってしまった価値観を捨てることは難しいため、日常的に何をunlearningしたいのかを考え意識的に習慣や行動を変えることが必要とのことでした。 発表中にunlearningを体験するために、2人1組で相手が空中に書く数字を反対側からなぞるというペアワークを行なったり、自分がunlearningしたいものを書いて紙飛行機を飛ばしたりと体験が混ざった発表で楽しかったです。 まとめ 今回私にとって初めての海外カンファレンス参加でしたが、会場の雰囲気がとても暖かくオープンで世界中から集まったRubyist達と交流できた素晴らしい経験になりました。 ロサンゼルスは少し肌寒かったです。それなのに会場は冷房がかかっていて思わぬカルチャーショックでした。食べ物に関してはさすがアメリカの中でも特に人種的な多様性に富んだ州ということで、様々な国の食べ物を楽しむことができました。特にメキシコ料理が良かったです。 講演は全て英語だったわけですが、中には早口なスピーカーもそれなりにいて英語慣れしていない人には厳しいように感じました。個人的には会話中に声量がなさ過ぎて聞き返されることが多々あったので、少しうるさいと感じるくらいの声量を意識して会話をしていました。 また、今回のRubyConf参加に関する費用はすべて会社が負担してくれました。 来年のRubyConfはテネシー州ナッシュビルで開催予定です。一緒に行きたい！　という方がいましたら、ぜひ以下のリンクからご応募ください。お待ちしております。 www.wantedly.com

こんにちは。イノベーション推進部の武田です。 Google Assistantアプリを開発するときの本番環境と開発環境の切り分けについて紹介します。 はじめに 最近Google AssistantやAlexaなどのVoice User Interfaceが熱いですね。 毎日のように新しい記事を目にしますし、新しいハードもどんどん登場しています。 プラットフォームごとにSDKも公開されており、誰でもアプリを開発し公開できます。 開発の初期段階では自分だけが触るので、試せる環境が1つあれば十分です。 しかし、開発したアプリを審査に出したりリリースしたとなるとそうは行きません。 そこで 審査や実際に稼働している処理に開発の影響を出さない ことを目的とした環境の構成を紹介します。 アプリの構成と役割 Google Assistantアプリは基本的にActions on GoogleとDialogflow、 そしてCloud Functionsなどのバックエンドサーバーの3つで構成されています。 簡単に説明すると以下のような役割を持ちます。 Actions on Google アプリ自体の管理を担当。アプリ名や言語などを設定したり、審査やリリースといった操作が可能。 Dialogflow 発話内容の分析を担当。会話のパターンや認識する単語を設定できる。 バックエンドサーバー（Cloud Functionsなど） 発話内容に応じて任意の処理を実行する。自分でサーバーを用意することになるため、AWS Lambdaなどでも良い。 ユーザーからのリクエストを含めた処理の流れが下記の図です。 場合によってはバックエンドサーバー自体がなかったり、 バックエンドサーバーの先に別のAPIだったりDBだったりがつらなってきます。 今回は図に示した構成で考えていきます。 本番環境と開発環境の切り分け 切り分けにはActions on GoogleのスナップショットとGoogle Cloud Platform（以降GCP）のプロジェクトを利用します。 図にすると以下のようになります。 切り分け方ごとに説明して行きましょう。 Actions on GoogleとDialogflow Actions on GoogleとDialogflowはスナップショットの仕組みを利用します。 Actions on Googleはバージョン管理機能を備えており、 スナップショットは各バージョンの処理内容を保存したものです。 スナップショットは審査の提出やテスターへの配信の際に自動で作成されます。 開発している途中のようにスナップショット作成時から何かしら変更がある場合、 現在の状態はドラフトとして保存されています。 作成されたスナップショットは、審査やテスト配信など状況に合わせた環境へデプロイされます。 開発中の内容が保存されているドラフトは、開発者のアカウントやシミュレーターで実行可能です。 そのため、無理に別のプロジェクトに分けなくても動作環境は分離されているわけです。 バックエンドサーバーの接続先はDialogflowで設定します。 スナップショットとドラフトで別の設定をしておけば、 リクエストを別々のバックエンドサーバーに飛ばすことができます。 ただ、接続先を手動で切り替えることになるため開発体制によっては何かしら対策が必要です。 Actions on GoogleとDialogflowもGCPの一部であるため、 プロジェクト自体を切り替えて環境を分けることは可能です。 しかし、これらはGUIでの操作がメインです。 プロジェクトを分けると情報の同期が手間になってしまうので、スナップショットを利用する方法を取っています。 バックエンドサーバー（Cloud Functions） Cloud Functionsを利用している場合、 GCPのプロジェクトを別にしてしまうのが良いと思います。 下の図の赤枠の部分です。 Cloud Functionsはデプロイせずにローカルで検証していくことがある程度可能ですので、 プロジェクトを分けなくても動作環境は分離できます。 しかし、Google Homeなどのデバイスやシミュレーターで会話の検証をする場合、 設定したエンドポイントにリクエストが飛ぶことになるためデプロイが必須となってきます。 また、開発するアプリがFirebaseのMessagingやFirestoreを利用していると、 プロジェクトを切り替えれば全てまとめて切り替わってくれるのは楽です。 複数のプロジェクトの管理はFirebase CLIを利用すれば簡単に行えます。 まとめ この方法を使えば、審査や本番に影響を出さずに開発もガンガン進めていくことが可能です。 しかし途中で挙げた手動切り替えなどの問題を考慮すると、 Actions on GoogleとDialogflowも別プロジェクトに切り分けた方がいい状況もあると思います。 このあたりはCLIでの管理が進んできたり、開発のプラットフォームが安定したら考えていきたいところです。 VUIはチャレンジングで非常に面白い領域です。 プロダクトのUXを考えるのもそうですし、開発の方針や設計も手探りな状態なのでやること全てが挑戦です。 今回は技術寄りの内容でしたが、もっとプロダクト寄りの話もしていきたいと思ってます。 最後に DroidKaigi 2019 に採択されました！ Google Assistantアプリのベータテスター配信やCLIでテストしやすい構成など、ちゃんとサービスを作るための内容を発表します。 もし都合が合う方はぜひお越しください！ VUI界隈を盛り上げたかったり、新しいプロダクトを作りたい人を募集中です！ 一緒に世界をカッコよくしていきましょう！ www.wantedly.com

こんにちは。品質管理部エンジニアリングチームの遠藤です。 私の所属している品質管理部では、業務の一環として、ZOZOSUIT計測精度の向上のために新しいアプリがリリースされる度に精度のチェックを行っております。 常に計測、比較、検証などを行っており、特に計測は実際にZOZOSUITを着用し、計測、結果の記録を行っているのでとても時間がかかる作業です。 計測プロセス自体は毎回（大体）同じなので、その点をエンジニアリング的に解決できないか試してみました。だってエンジニアリングチームなんですもの！ どうやって計測するか 最初大まかに考えた構成は、ディスプレイに写真を表示して、その写真を適度なタイミングで撮影、計測、計測値の取得という流れです。 効率のため並列で動くようにして、だれでも気軽に動かせる画面を用意する、こんな感じでしょうか。 実現には様々な技術を組み合わせる必要があるかと思いますが 今回はその中で音声認識についてスポットを当ててみようと思います。 音声認識について ZOZOSUITの計測は主に音声案内が使われています。まずそこをどうすればいいか考えました。なら音声認識すればいいのでは？ という単純な理由で音声認識を調べると、Google Speech APIというホットなサービスがありました。有料ですが初回利用時に300ドル分のトライアルを無料でもらえたのでそちらを利用させていただくことにしました。 単純な音声認識をしてみる（python3） とりあえず、Googleのサンプルを実行してみました。 音声ファイルはZOZOTOWNアプリの計測時の「もう一度数字を読み上げます。数字を押してください　9」というおなじみの音声をMacBook Proの内蔵マイクで録音したものを使ってみました。 import io import os # Imports the Google Cloud client library from google.cloud import speech from google.cloud.speech import enums from google.cloud.speech import types # Instantiates a client client = speech.SpeechClient() # The name of the audio file to transcribe file_name = os.path.join( os.path.dirname(__file__), 'resources' , 'audio.wav' ) # Loads the audio into memory with io. open (file_name, 'rb' ) as audio_file: content = audio_file.read() audio = types.RecognitionAudio(content=content) config = types.RecognitionConfig( encoding=enums.RecognitionConfig.AudioEncoding.LINEAR16, # sample_rate_hertz=16000, # language_code='en-US') sample_rate_hertz= 44100 , language_code= 'ja-JP' ) # Detects speech in the audio file response = client.recognize(config, audio) for result in response.results: print ( 'Transcript: {}' . format (result.alternatives[ 0 ].transcript)) Googleのサンプルそのままですが。 sample_rate_hertz= 44100 language_code= 'ja-JP' 'audio.raw' → 'audio.wav' の部分のみ音声ファイルに合わせて変更しています。 それでは実際に実行してみましょう。 ラジオしてくださいって！ どうやらうまく認識できていないようです。 いろいろ記事をみてみると、Google Speech APIの認識率はとても高いようですので、音声ファイルに何らかの原因がありそうです。 音声ファイルを聞いてみて気になった点としては 最初に何秒か無音部分がある 環境を気にせず録音したためエコーがかったように聞こえる 音声のボリュームが小さい というのがありました。 その点を注意し試しに別の音声を取り込んでみると、 今度はうまくいきました。 音声認識の手順がわかったところで今度は音声の取り込みを試します。 静かな部屋の中、一台の端末を行うなら内臓マイクで録音するのも良いかと思いますが、複数端末を行いたいのでAndroid端末のイヤホンジャックから音声を取り込むことにします。 音声デバイスのインデックスはこちらのコードで確認できます。 import pyaudio audio = pyaudio.PyAudio() for i in range (audio.get_device_count()): dic = audio.get_device_info_by_index(i) print (dic[ 'index' ], dic[ 'name' ]) 0 Built-in Microphone 1 Built-in Output 2 DisplayPort 3 HDMI Androidのヘッドフォン端子から音声を入力するために マイク端子を増設するケーブルをUSBに接続するとこのように表示されます。 0 Built-in Microphone 1 Built-in Output 2 DisplayPort 3 HDMI 4 USB PnP Sound Device 4の USB PnP Sound Device を指定して録音を行えばケーブルからの音声の取り込みで動作させられそうです。 実際このようなシステムを構築し、実験してみました。 実際にやってみて アプリの流れに沿って音声認識でデバイスを制御してみると、いろいろと問題があることを把握できました。 言葉の区切りごとでAPIにリクエストすれば高い精度で認識してくれるのですが、言葉の途中でリクエストしてしまうとそこで聞き取った音声がうまく認識されませんでした（当たり前ですね）。 また、タイミングよくリクエストしても、APIからの返答までに次の音声案内に入ってしまうという問題もありました。 対策として 音声ボリュームを確認しながら無音が何秒かあった場合は言葉の区切りと見なしてみたり、 リクエスト中に別スレッドが録音を担当するように手分けしてみました。 それでも100％に近いかたちで音声を認識させることは難しかったです。 また録音した音声を実際に聞いてみるとなぜか音声にノイズが含まれていることもわかりました（試せていないのですが、もしかしたらオーディオ変換ケーブルの相性があるかもしれません）。 結論 単純に音声認識をすることは問題なく行えたのですが、実際にそれを組み込み、意図した動作させることにはまだまだ課題がありそうです。 感想 一通り構築してみて、うまくいかなかった点はありましたがいろいろ学ぶことはとても多かったです。 音声認識については意図した動作をさせることができませんでしたが 「それは失敗ではなくて、その方法ではうまくいかないことがわかったんだから成功なんだ」 ってエジソン先生も言ってることですし、試してみて問題があれば、ひとつひとつ解決していく方法を探していきたいと思います。 参考サイト Cloud Speech-to-Text API　クイックスタートクライアント ライブラリの使用 https://cloud.google.com/speech-to-text/docs/quickstart-client-libraries?hl=ja#client-libraries-install-python 最後に ZOZOテクノロジーズでは、一緒にサービスを作成、サポートしてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ https://www.wantedly.com/companies/starttoday-tech/projects

ZOZO研究所でインターンをしている松井です。本記事では、cross-domain画像検索とdeep metric learningの概要と、cross-domain画像検索で良い精度を達成するためのテクニックを取り上げます。 metric learningの概要 metric learning とは、データ間の関係を表す計量（距離や類似度など）を学習する手法です。 画像分類や、画像検索などに応用できます。 意味の近いデータの特徴量どうしは近く、意味の異なるデータの特徴量どうしは遠くなるような計量を学習 します。 意味の近いデータのペアを positive pair 、意味の異なるデータのペアを negative pair と呼びます。 deep learningが出てくる前の代表的な手法として、マハラノビス距離の共分散行列を学習させる手法があります。 ：データの特徴量 ：パラメータ（共分散行列） この を、positive pairならば小さく、negative pairならば大きくする損失関数で学習をします。 前述したマハラノビス距離の式において と分解すると、以下のように表すこともできます。 ：ユークリッド距離 つまり、マハラノビス距離の共分散行列を学習することは、 ユークリッド距離においてpositive pairならば近く、negative pairならば遠くなるような特徴量 を抽出する行列 を学習 することとも捉えられます。 をかけることは線形写像ですが、その代わりに非線形写像をdeep learningで学習する手法が、 deep metric learning です（以下、DMLと略します）。 ：非線形写像 ：パラメータ metric learningの応用 metric learningの代表的な応用である、 fine-grained image classification と cross-domain画像検索 を紹介します。 fine-granined image classification fine-grained image classification とは、以下の入出力を持つタスクです。 入力：画像 出力：画像に映る物体のクラス fine-grained image classificationでは車や鳥といった大雑把なクラスを予測するのではなく、 車種や鳥の種類など、より細かいクラス を予測します。 クラス数が多く、クラスあたりの画像数が少ない 状況です。 metric learningを用いて解くとき、positive pairとnegative pairを以下のように定義します。 positive pair：同じクラスの画像ペア negative pair：異なるクラスの画像ペア そして、学習した距離を用いたk-nearest neighborで分類問題を解きます。 つまり、分類したいデータに最も近いk個のデータのクラスを見て分類します。 metric learningでは、学習時の入力が画像1枚ではなく画像のペアなので、1クラスあたりの学習データを大幅に増やすことができます。 そのため、クラスあたりの画像数が少ないfine-grained image classificationにmetric learningは適しています。 また、手法の評価方法は予測クラスが合っていれば正解として、accuracyを用いることが多いです。 cross-domain画像検索 cross-domain画像検索 とは、以下の入出力を持つタスクです。 入力：クエリ画像 出力：クエリ画像に対応する、ドメインの異なる画像 今回は、ファッションの画像を扱います。入出力は具体的に以下になります。 入力：スナップ写真中の検索したいアイテム領域（以下street queryとする） 出力：そのアイテムの商品画像（以下shop imageとする） metric learningを用いて解くとき、positive pairとnegative pairを以下のように定義します。 positive pair：同じ商品のstreet queryとshop imageのペア negative pair：異なる商品のstreet queryとshop imageのペア 商品IDをクラスとみなすと、クラスあたりの画像が少ない状況はfine-grained image classificationと同じです。 ですから、同様の理由でcross-domain画像検索にもmetric learningを用いることができます。 fine-grained image classificationと異なる点は以下の3が挙げられます。 ペア間で画像のドメインが異なる クラス（商品ID）あたりの画像数が1枚だけで、より少ない 同じ商品なのに似ていないペア（hard positive pair）や、異なる商品なのに似ているペア（hard negative）がいくつか存在する 手法の評価方法は、検索結果の上位k個にstreet queryと同じ商品が含まれていれば正解として、top-k accuracyを用いることが多いです。 metric learningの研究では、モデルの評価は主にfine-grained image classificationのタスクで行われています。 cross-domain画像検索を用いた評価は、主流ではありません。 DMLの手法を構成する項目 DMLの手法はいくつかの項目で構成されます。 例えば、計量として類似度と距離どちらを用いるのかや、どのような損失関数で距離を小さく・大きくするかなどがあります。 この章では以下の4つの各項目において、どのような選択肢があるのかを紹介します。 サンプリング ネットワークの構造 計量 損失関数 サンプリング metric learningの文脈におけるサンプリング方法とは、入力データの作り方です。 代表的なものとして、 contrastive sampling 、 triplet sampling があります。 contrastive samplingのバッチ内のサンプルは以下になります。 ：positive pair ：negative pair ：pairの起点となるサンプル（以下、anchorとする） 例：street query ：anchorに対して、positiveな関係にあるサンプル（以下、positiveとする） 例：同じ商品のshop image ：anchorに対して、negativeな関係にあるサンプル（以下、negativeとする） 例：異なる商品のshop image triplet samplingのバッチ内のサンプルは以下になります。 $$ (a, p, n) $$ また、 N-pair sampling が以下の論文で提案されました。 (K. Sohn. 2016) Improved Deep Metric Learning with Multi-class N-pair Loss Objective. N-pair samplingのバッチ内のサンプルは以下になります。 $$ (a_i, p_i, \left\{n_j\right\}_{j=1, j \neq i}^B) $$ ：anchorとpositiveの添字 ：バッチサイズ バッチ内の他の商品のpositiveをすべてnegativeとして扱います。 contrastive samplingやtriplet samplingに比べ、1サンプルにつき複数のnegativeを考慮できます。 metric learningでは、学習が進むに連れて、十分離れたnegativeが増えてきます。 1サンプルにつき1つのnegativeしか考慮しないと、十分離れたnegativeをサンプルしてしまった場合、重みが更新されません。 そのため、contrastiveやtripletよりN-pairのほうが学習の効率が良いとされています。 ネットワークの構造 基本的な構造は、ImageNetでpre-trainしたCNNの先にFC（全結合）層を1層つけた形になります。 構造の項目として、今回は以下を考えました。 CNNをstreetとshopで分けるか FCをstreetとshopで分けるか 上の2つの項目はcross-domain画像検索のときのみ考えます。 理由は、ドメインごとに異なる特徴抽出器を学習させたほうが精度を上げられる可能性があるためです。 計量 代表的な計量として以下の3つが挙げられます。 類似度 コサイン類似度 内積 距離 ユークリッド距離 ※正しくは、類似度を計量と呼びません。距離と類似度の総称が無いため、この記事では便宜上、まとめて計量と呼ぶことにします。 損失関数 この記事では、効率の良いN-pair samplingについてのみ扱っていくので、N-pair samplingのときの損失関数について取り上げます。 今回は、以下の2つの損失関数を取り上げます。 hinge loss SCE（softmax cross-entropy）loss hinge loss hinge lossは以下の式で表されます。 $$ L_{U} = \frac{1}{B} ( \sum_{i=1}^B{ \sum_{j=1 , j \neq i}^B{ \max( 0, d_p^{(i)} - d_n^{(i,j)} + m ) } }) $$ $$ d_p^{(i)} = d(x_{U}^{(i)}, x_{V}^{(i)}) $$ $$ d_n^{(i, j)} = d(x_{U}^{(i)}, x_{V}^{(j)}) $$ ：ミニバッチサイズ ：マージン ：anchor、positiveの添字 ：negativeの添字 ：positive pair間のユークリッド距離 ：negative pair間のユークリッド距離 ：ネットワークで抽出した画像特徴量 ：ドメイン hinge lossは、 を より小さくしようし、 という式を満たすよう学習させます。 以下の図のように、positiveとの距離+マージンの外にnegativeを追いやるよう学習させます。 なお、計量が類似度ならば符号を逆にします。 また、上の式はドメイン の画像特徴量をanchorとしていますが、 と を入れ替えた との和を最終的な損失関数とします。 $$ L = L_{U} + L_{V} $$ SCE loss SCE lossは以下の式で表されます。 $$ L = - \frac{1}{B} \sum_{i=1}^B \sum_{k=1}^B y_{(i,k)} \log{ P_i(k) } $$ 確率 を1に、それ以外の確率は0にしたい場合、 の項だけが残るよう、 を以下のように定義します。 $$ y_{(i,k)} = \begin{cases} 1 & (k=k_1) \\ 0 & (k \neq k_1) \end{cases} $$ 類似度を用いて確率を表すとSCE lossは以下のように表せます。 $$ L = - \frac{1}{B} \sum_{i=1}^B \sum_{k=1}^B y_{(i,k)} \log{ \frac{ \exp{s^{(i,k)}} }{ \sum_{j=1}^B \exp{s^{(i,j)}} } } $$ ：サンプル とサンプル の類似度 今、positive pairの類似度 を大きくし、negative pairの類似度 は小さくしたいです。 すなわち、 にして、それ以外の確率は0にしたいので、 の項だけ残します。 $$ L = - \frac{1}{B} \sum_{i=1}^B \log{ \frac{ \exp{s^{(i,i)}} }{ \sum_{j=1}^B \exp{s^{(i,j)}} } } $$ $$ = \frac{1}{B} \sum_{i=1}^B \left\{ - s^{(i,i)} + \log{ \sum_{j=1}^B \exp{s^{(i,j)}} } \right\} $$ 上の式は、類似度を使ったhinge lossと似ています。 ただ、negative sample ついてhinge lossでは平均をとっていますが、SCE lossではLogSumExpをとっています。 hinge lossではバッチ内のnegative pairが離れていくに連れlossが小さくなります。 しかし、 SCEではバッチ内に1つでも十分離れていないnegativeが存在すればlossは大きいまま です。 よって、以下の論文ではSCE lossのときの学習効率のほうが良いとされています。 (K. Sohn. 2016) Improved Deep Metric Learning with Multi-class N-pair Loss Objective. fine-grained image classificationで有効な慣習がcross-domain画像検索では有効とは限らない 今回、cross-domain画像検索を試作しました。 そのとき、fine-grained image classificationでは有効である慣習の1つが、cross-domain画像検索では有効でないことがわかりました。 試作の条件 以下の条件で試作を作りました。 サンプリング：N-pair sampling ネットワークの構造：CNN, FC共有 計量：コサイン類似度 損失関数：hinge loss マージン：1.0 CNNはInception V3を用い、ImageNetでpre-trainした重みを採用しました。 CNNを、出力が2048次元の特徴抽出器としました。 CNNの重みはmetric learningでfine-tuningしました。 FCの出力は512次元にしました。 データセットの各サンプルは以下の形をしています。 $$ (I_{strt}, I_{shop}) $$ ：WEARのスナップ画像からSSDで検出したアイテム領域 ：それに対応するZOZOの商品画像 trainデータでは60,000サンプルを使用しました。 最適化手法はAdamを用いました。Adamのハイパーパラメータは としました。 バッチサイズは30としました。 1,000 iteration学習させました。 評価方法 評価指標は Acc.@k/N（Top-k Accuracy against N items） を用いました。 学習したネットワークで抽出したstreet queryとshop imageの特徴量でk近傍探索を行います。 つまり、N枚のshop imageから、あるstreet queryと似ている画像を検索します。 そして、検索結果の上位k個の中に同じ商品のshop imageが含まれれば正解=1とします。 含まれなければ、不正解=0とします。 N枚のstreet queryに対し、上記の操作を繰り返し、平均を取った値がAcc.@k/Nです。 値が高いほど、良いです。 通常、Nの方は明記されませんが、以下の論文ではNが大きくなるに連れてAcc.@kの値は減少する結果が出ています。 ですから、結果の比較をしやすくするため、あえてNを明記しました。 (J. Huang, R. S. Feris, Q. Chen, & S. Yan. 2015) DARN | Cross-domain Image Retrieval with a Dual Attribute-aware Ranking Network. 今回は、Acc.@20/1000を用いました。 以降、簡単のため、この指標を単に精度と呼ぶことにします。 評価に用いるtestデータはtrainデータとは異なる1,000サンプルを用いました。 結果 HingeCosM1.0：試作 ImageNet：ImageNetで学習したCNNにより抽出した特徴量を用いた方法 試作は、ImageNetよりも精度が低かったです。 精度改善のため、hinge lossがちゃんと機能しているかを調べました。 バッチ内のanchor・positive・negative間のコサイン類似度が学習によってどう変化するかをプロットしました。 anc_pos：positive pair間のコサイン類似度の平均 anc_neg：negative pair間のコサイン類似度の平均 pos_neg_strt：street query間のコサイン類似度の平均 pos_neg_shop：shop image間のコサイン類似度の平均 学習が進むにつれ、anc_posとその他との差が開いていったことがわかります。 すなわち、同じ商品は近くに、異なる商品は遠くに埋め込まれたと考えられます。 この図だけ見ると、hinge lossは意図した通りに機能していたようです。 ここで、学習による精度の変化も見てみます。 初めは、一気に精度が上がり、そこから徐々に落ちていったことがわかります。 また、検索結果も見てみます。 query item 正解のshop image ImageNet HingeCosM1.0 各手法の検索結果の上位20個のshop image（左から右、上から下の順） ImageNetの結果ほうがstreet queryに近い柄のアイテムが検索されました。 次に、testデータの、各shop queryに対する1,000 shop imagesのコサイン類似度のヒストグラムを見ました。 横軸がコサイン類似度で、縦軸は頻度です。 類似度が1か-0.3付近に集中していることがわかります。 つまり、どちらかといえば似ているshop imageの類似度はほぼ1になっていると考えられます。 この現象の原因は、学習データにhard positive pair（同じ商品だが似ていないペア）が多く含まれるためだと考えられます。 hard positive pairの類似度を上げようとすると、学習していないnegative pairのうち、hard positive pairより似ているものの類似度はより高くなる可能性があります。 つまり、同じ商品なのに似ていないペアの類似度を上げようとすると、より似ている異なる商品との類似度も上げてしまう可能性があるということです。 そのため、あまり似ていない商品が含まれる結果になったと考えられます。 すなわち、マージン=1.0だと、hard positive pairに引っ張られて過学習を起こしやすいと考えられます。 そこでマージンを小さくすることで、どちらかといえば似ている商品の類似度を程よい値（0.5など）にでき、精度があがると考えました。 実験 マージンを小さくすると精度があがるかを検証するための実験を行いました。 比較する条件は以下の3つです。 HingeCosM1.0：マージン=1.0（先程の試作） HingeCosM0.5：マージン=0.5 HingeCosM0.1：マージン=0.1 結果 マージン=0.5のときが最も良い精度となりました。 query item 正解のshop image ImageNet HingeCosM1.0 HingeCosM0.5 HingeCosM0.1 各手法の検索結果の上位20個のshop image（左から右、上から下の順） 検索結果も、マージン=0.5のときの柄が最もshop queryに似ていました。 なお、shop queryの色と検索結果のshop imageの 色が異なるのは、同じ商品でも異なる色のペアがデータセットに含まれていたため だと考えられます。 そのようなペアをデータセットから除けば、検索結果に色も反映できる と思われます。 次に、testデータのコサイン類似度のヒストグラムも見てみます。 HingeCosM1.0 HingeCosM0.5 HingeCosM0.1 マージン=1.0にくらべ、マージン=0.5のときの類似度は-0.25から1にかけてなだらかに分布してるのがわかります。 マージン=0.1のときはそもそも類似度の差が開いていないため、精度が悪かったと考えられます。 結論 既存のmetric learningの研究では、マージンは大きいほうが良いという慣習がありました。 しかし、既存の研究では、fine-grained image classificationで評価することがほとんどです。 今回、マージンの大きさによるcross-domain画像検索の精度を計測したことで、cross-domain画像検索においてマージンを大きくすることは有効でないことがわかりました。 マージンを大きくするとhard positiveに引っ張られてしまい、hard positiveが多く含まれるcross-domain画像検索では精度が落ちることがわかりました。 また、マージン以外にも、既存の研究で有効とされている慣習がcross-domain画像検索では有効とは限らない可能性があると考えられます。 Cross-domain画像検索で有効なテクニックの探索 さらなる改善のため、マージン以外の項目も同時に探索しました。 探索範囲 以下の項目の組合せを探索しました。 CNNの構造 共有するか 分けるか CNNの重み ImageNetの重みで固定するか fine-tuingするか FCの構造 共有するか 分けるか 計量 類似度 コサイン類似度 内積 距離 ユークリッド距離 損失関数 hinge loss SCE loss（計量が類似度のときのみ） マージン（hinge lossのときのみ） 1.0, 0.7, 0.5, 0.3, 0.1（計量がコサイン類似度のとき） 625, 437, 312, 187, 62（計量が内積のとき） 12250, 3240, 1440, 490, 40（計量がユークリッド距離のとき） FCを分ける場合、重みの初期値を共有にしないと精度が一向に上がりませんでした。 初期値を共有にすることで学習が安定したので、今回はFCを分けるとき、初期値は共有しました。 ユークリッド距離とSCE lossを同時に用いるなどの妥当でない組合せを除き、230条件を探索しました。 1000 iterationだけ学習させ、10 iterationごとに精度を見て3回連続で落ちた場合、学習を打ち切りました。 評価には最後のiterationの重みを用いました。 上記の条件以外は、試作の条件と同じです。 マージンの探索範囲は、コサイン類似度のときのマージンの範囲を各計量に応じて変換しました。 学習初期の画像特徴量ベクトルのノルムが約25だったので以下の式で変換しました。 内積のときは以下の変換を用いました。 $$ m_{dot} := ||x||^2m_{cos} = 625 m_{cos} $$ ：内積のときのマージン ：画像特徴量ベクトルのノルム ：コサイン類似度のときのマージン 内積は、コサイン類似度に両ベクトルのノルム（ ）をかけたものなので、マージンも 倍しました。 ユークリッド距離のときは以下の変換を用いました。 $$ m_{euc} := \sqrt{ 2 (1-\sqrt{1-m_{cos}^2}) }||x|| $$ $$ = 25\sqrt{ 2 (1-\sqrt{1-m_{cos}^2}) } $$ ：ユークリッド距離のときのマージン また、実装の都合上、距離ではなく距離の二乗を採用したため、マージンも二乗した を用いました。 ユークリッド距離のときのマージンの変換の導出は、付録1で説明します。 結果 探索範囲の内、最良の条件は以下で、Acc.@20/1000=48.4％に達しました。 CNNの構造：共有する CNNの重み：fine-tuingする FCの構造：分ける 計量：内積 損失関数：hinge loss マージン：187 なお、349 iterationで打ち切られていたため1000 iterationまで学習させたところ、Acc.@20/1000=57.1％に達しました。 以降、上の条件をHingeDotM187SpFcと呼ぶことにします。 下の図からわかるように、前の章で最も良かったHingeCosM0.5に比べて大幅に精度が良くなりました。 検索結果は以下になります。 query item 正解のshop image HingeCosM0.5 HingeDotM187SpFc 各手法の検索結果の上位20個のshop image（左から右、上から下の順） HingeDotM187SpFcの方が、street queryの柄により近い結果となりました。 また、各項目による精度の違いを見ていきます。 下記の表では計量とCNNの重みの条件以外は、CNNとFCともに共有、Hinge lossで固定したときの精度です。 条件 計量 CNNの重み Acc.@20/1000 HingeCosM0.5 コサイン類似度 fine-tuning 0.283 HingeCosM0.5Fx コサイン類似度 固定 0.152 条件 計量 CNNの重み Acc.@20/1000 HingeDotM187 内積 fine-tuning 0.469 HingeDotM187Fx 内積 固定 0.132 条件 計量 CNNの重み Acc.@20/1000 HingeEucM324 ユークリッド距離 fine-tuning 0.442 HingeEucM324Fx ユークリッド距離 固定 0.136 Mの後の数字はマージンです。 どの計量においても CNNをfine-tuningしたほうが良かった です。 また、計量に関して 内積とユークリッド距離が、コサイン類似度より大幅に良かった です。 マージンを変えたときや、CNNやFCをそれぞれ分けたときにおいても同様の結果が得られました。 また、画像特徴量のノルムの、学習による変化を見てみます。 まず、以下がHingeEucM324のとき。 次に、以下がHingeDotM187のとき。 norm_strtがstreet query、norm_shopがshop image、の画像特徴量のノルムを表します。 どちらも 学習につれ特徴量のノルムが大きくなりました。 次に、CNNを分けたときと共有したときの精度の学習による変化を見ます。 SpCnnと書かれたオレンジの線がCNNを分けた条件で、青い方がCNNを共有した条件です。 CNNを共有したほうが、少ないiterationで良い精度に達しました。 他の計量やマージンを用いたときや、FCを分けときも同様の結果が得られました。 次に、FCを分けたときと共有したときの精度の学習による変化を見ます。 SpFcと書かれたオレンジの線がFCを分けた条件で、青い方がFCを共有した条件です。 FCを分けても、あまり大差はありませんでした。 他の計量やマージンを用いたときや、CNNを分けときも同様の結果が得られました。 次に、損失関数による精度の違いを見てみます。 条件 計量 損失関数 Acc.@20/1000 HingeCosM0.5 コサイン類似度 hinge loss 0.283 SceCos コサイン類似度 SCE loss 0.168 条件 計量 損失関数 Acc.@20/1000 HingeDotM1870 内積 hinge loss 0.469 SceDot 内積 SCE loss 0.049 どちらの計量においても、 損失関数はSCE lossよりhinge lossのほうが良かった です。 考察 CNNの重みを固定すると、FC1層のパラメータによる表現力が足りなかったため、精度が落ちたと考えられます。 コサイン類似度に比べ、内積とユークリッド距離の方が大幅によかった理由は、ノルムを大きくすることでマージンによる悪影響を小さくできたためと考えられます。 ノルムを大きくするとマージンによる影響を小さくできたことについては、付録2で説明します。 fine-grained classificationにおいては、hinge lossよりSCE lossの方が良い結果を出しています。 一方、cross-domain画像検索では、マージンを大きくすることに加え、SCE lossを用いることも有効でないことがわかりました。 まとめ 既存のmetric learningの慣習が必ずしもcross-domain画像検索では有効とは限らないことがわかりました。 また、cross-domain画像検索においてDMLを用いる場合、以下のテクニックが有効だとわかりました。 少ないiterationで良い精度に達したければ、CNNは共有にする CNNはImageNetの重みからfine-tuningする 計量は内積を用いる 損失関数はSCE lossでなくhinge lossを用いる マージンは大きくしすぎない 付録1：ユークリッド距離のときのマージンの変換の導出 コサイン類似度では、以下のようにpositiveとnegativeの類似度を、最悪でもマージン分だけ差をつけたいです。 $$ \cos{\theta_p} = \cos{\theta_n} + m_{cos} $$ ：positiveの角度 ：negativeの角度 また、positiveとnegativeの離したい角度を とすると、 と表せます。 このときpositiveとnegativeの距離は、 の成す弦と一致するので、以下で表せます。 $$ m_{euc} = 2 ||x||\sin{\frac{\theta}{2}} $$ $$ =\sqrt{2(1-\cos{\theta})}||x|| $$ 今、 、 としたいので以下のようになります。 $$ \cos{\theta} $$ $$ =\cos{(\theta_n-\theta_p)} $$ $$ =\cos{\theta_n}\cos{\theta_p} + \sin{\theta_n}\sin{\theta_p} $$ $$ =\sqrt{1-m_{cos}^2} $$ よって、以下の変換を用いました。 $$ m_{euc} := \sqrt{ 2 (1-\sqrt{1-m_{cos}^2}) }||x|| $$ 付録2：ノルムを大きくするとマージンの悪影響を減らせる理由 まず、内積のときの場合について説明します。 ノルムが大きくなるにつれ内積も大きくなるので、マージンが相対的に小さくなります。 よって、コサイン類似度に比べ、マージンの影響を受けづらかったのだと考えられます。 また、ユークリッド距離の二乗を展開すると、内積のときと本質的に同じことがわかります。 ユークリッド距離を用いたhinge lossは以下を小さくしたいです。 $$ d_p^2 - d_n^2 $$ ：positive pairのユークリッド距離 ：negative pairのユークリッド距離 距離を展開します。 $$ d_p^2 - d_n^2 $$ $$ = ||x_a-x_p||^2 - ||x_a-x_n||^2 $$ $$ = - 2x_a^Tx_p + 2x_a^Tx_n + ||x_p||^2 - ||x_n||^2 $$ ：anchorの画像特徴量 ：positiveの画像特徴量 ：negativeの画像特徴量 今、positiveとnegativeのドメインは同じなので、それぞれのノルムは同じとみなすと以下を小さくしたいということになります。 $$ - x_a^Tx_p + x_a^Tx_n $$ つまり、positive pairの内積は大きく、negative pairの内積は小さくしたいということになります。 よって、ユークリッド距離を用いたmetric learningは内積を用いた場合と本質的には同じだと考えられます。 ですから、内積のときと同様の理由で、マージンの影響を受けづらかったのだと考えられます。 最後に 研究所ではcross-domain画像検索以外にも「似合う」ということについて多角的に研究を進めています。機械学習に限らず、専門性を活かしてファッションを分析できる環境を提供しています。ファッションに関する研究テーマに挑戦したい方はぜひ下のリンクから応募して、ぜひ一度オフィスに来ていただければと思います。 www.wantedly.com 参考サイト、文献 Metric learning/similarly learningに関する資料集 - めも 距離計量学習とカーネル学習について - a lonely miner Similarity Learning with (or without) Convolutional Neural Network - Moitreya Chatterjee, Yunan Luo ronekko/deep_metric_learning: Deep metric learning methods implemented in Chainer

こんにちは、最近気になっている哺乳類は オリンギート な、開発部の塩崎です。 私の所属しているMarketingAutomationチームではRealtimeMarketingシステムの開発運用を行っております。 このシステムはZOZOTOWNのユーザーに対してメールやLINEなどのコミュニケーションチャンネルを使い情報の配信を行うものです。 メルマガの配信数や開封数などの数値は自動的に集計され、BIツールであるRedashによってモニタリングされています。 このRedashは社内PCによってホスティングされていましたが、運用面で辛い部分が多々あったためパブリッククラウドに移行しました。 移行先のクラウドはawsを選択し、RedashをホスティングするためのサービスはECS/Fargateを選択しました。 この記事ではawsに構築した環境や、移行作業などを紹介します。 移行前のRedash 移行前のRedashの問題点 現行のRedashの紹介 技術選定 構成を詳細に説明 RDS(PostgreSQL) + ElastiCache(Redis) ECS/Fargate Datadog Fargateの利点欠点 利点 EC2の管理から解放される コンテナ数のスケーリングをするときにEC2のスケーリングをしなくても良い AutoNamingによるサービスディスカバリは便利 欠点 コンテナのデプロイが遅い 同一タスク中の複数のプロセスが同じポートで待受できない ログドライバーがawslogsしか選択できない previllegeモードでDockerを動かすことができない まとめ 移行前のRedash 移行前のRedashがどのような環境でホスティングされていたのかを説明します。 Windowsの物理マシンがあり、そのなかにコンテナ管理ツールの Portainer が入っています。 RedashのwebサーバーやRedashを動作させるためのミドルウェアなどはすべてDockerコンテナの中で動いており、その管理をPortainerに任せています。 Redashのデータソースは主に2種類あり、それはBigQueryとPuredataです。 BigQuery はGoogle製の完全にマネージドなDWHです。 BigQueryとの接続にはRedashがデフォルトで用意しているインテグレーション機能を使用しています。 一方、PuredataはIBM製のDWHアプライアンスです。 こちらはRedashとのインテグレーションが用意されていません。 そのため、我々のチームでPuredataと接続するためのゲートウェイを作成し、Redashとの接続に使用しています。 Puredataに接続するためのインタフェースとしてIBMからJDBCドライバーが提供されています。 しかし、RedashはPythonで実装されており、JDBCドライバーを直接読み込むことができません。 何らかの仕組みでPythonとJavaの変換が必要です。 ですので、 Py4J を使いPythonからJavaのメソッドを呼ぶことでRedashからPuredataに接続しています。 参考： RedashとBigQueryのインテグレーション機能 移行前のRedashの問題点 上記で説明したような構成のRedashにはいくつかの問題がありました。 主には物理マシンの管理が面倒という内容です。 物理マシンが落ちた時の復旧が手動 何らかの原因で物理マシンが落ちたときには、物理マシンが置いてある場所まで行き、手動で起動をするという運用が必要になってしまっていました。 ビルの法定停電の時にマシンの電源を落とす必要がある ビルの法定停電の時には停電前に電源を落とし、停電から復旧した後に正常に動作するかどうかを確認する運用が必要になっていました。 現行のRedashの紹介 次にawsに構築したRedashの紹介をします。 Redashの動作に必要なミドルウェアはPostgerSQLとRedisです。 これらはawsのフルマネージドサービスであるRelational Database Service(RDS)とElastiCacheでホスティングすることによって、管理コストを下げました。 RedashとPuredataGatewayのDockerイメージはElastic Container Registry(ECR)で管理されており、ECSはここからdocker pullを行います。 DockerhubでホスティングされているRedash公式のDockerイメージを使わない理由は、Puredataに対応させるために独自のパッチを当てているためです。 次にコンテナ間通信について説明します。 RedashとPuredataGatewayの間はPy4JによるTCP通信をさせる必要があります。 しかしPuredataGatewayコンテナのIPアドレスは起動するごとに変化するので、Redashのコンテナの中にIPアドレスをハードコーディングすることはできません。 Redash workerコンテナがPuredataGatewayコンテナのIPアドレスを取得する仕組みが必要です。 NLBを使うことはその1つの解決策ですが、今回は最近東京リージョンでも使えるようになった Route53 Auto Naming で実現しました。 これはコンテナの起動・終了のタイミングでDNSのAレコードの値が自動的に増減する仕組みです。 Redash側からPuredataGatewayに接続するときにはこのAレコードを参照すれば、現在アクティブなPuredataGatewayのIPアドレスを得ることができます。 NLBではなくAutoNamingを利用した主な理由はロードバランサーを入れないほうが全体の構成がシンプルになるためです。 これらのインフラ構成はすべてCloudFormationで管理されています。 これ以降でインフラ構成を説明するときにはCloudFormationのテンプレートファイルを使って説明します。 また、これらのサービスの監視は Datadog で行っています。 RDSとElastiCacheは aws integration でメトリクスの収集を行っています。 そして、コンテナのメトリクスの収集はDatadog Agentのサイドカーコンテナを配置することで行っています。 FargateとDatadogの連携に関する設定はこの下で詳しく説明します。 技術選定 今回のRedashホスティングにFargateを選定した理由を説明します。 まず、Redashを動作させるためのDockerイメージが公式から提供されているので、それを使うことを考えました。 その場合、何かしらの仕組みでコンテナのオーケストレーションを行う必要があります。 マーケティングオートメーションチームは既にawsでのサービスの開発・運用実績がありましたので、パブリッククラウドとしてawsを選択しました。 awsでDockerのオーケストレーションをしてくれるマネージドサービスはECSとEKSがあります。 EKSはDocker界隈で最近ますます存在感を増しているkubernatesのマネージドサービスです。 ですが、コントロールプレーンのみがマネージドであり、ワーカーノードの管理は自分たちで行う必要があります。 今回は可能な限りインフラの管理をawsに任せたいという思いがあったため、ECS/Fargateを選択しました。 構成を詳細に説明 ここからは今回構築したRedash環境の詳細をCloudFormationのテンプレートファイルを交えながら説明していきます。 RDS(PostgreSQL) + ElastiCache(Redis) まずは、Redashが必要としているミドルウェアであるPostgreSQLとRedisを構築します。 どちらともawsによるマネージドサービスが提供されているので、RDSとElastiCacheを使うことにしました。 今回は高いSLOが求められないので、値段を優先して一番安いインスタンスを使ったシングルAZ構成で構築しました。 たとえシングルAZ構成でも、 OSのセキュリティパッチやデータベースのバックアップはaws側がやってくれます。 そのため、Redash公式のdocker-composeを使った構成よりも管理コストが低いです。 また、可用性を高めるためこれをマルチAZ構成にすることも比較的容易です。 Resources : RDSDBParameterGroupForRedash : Type : 'AWS::RDS::DBParameterGroup' Properties : Description : 'rds parameter group for redash' Family : 'postgres9.6' RDSDBSubnetGroupNameForRedash : Type : "AWS::RDS::DBSubnetGroup" Properties : DBSubnetGroupDescription : 'rds subnet group for redash' DBSubnetGroupName : redash-rds-subnet-group SubnetIds : - !Ref EC2SubnetApplicationPrivateAZ1 # 予め定義しておく - !Ref EC2SubnetApplicationPrivateAZ2 # 予め定義しておく EC2SecurityGroupRDSRedash : Type : 'AWS::EC2::SecurityGroup' Properties : GroupName : redash-rds-security-group GroupDescription : 'rds security group for redash' VpcId : !Ref EC2VPC SecurityGroupIngress : - SourceSecurityGroupId : !Ref EC2SecurityGroupECSRedash # ECSタスクに紐づけているセキュリティグループ FromPort : 5432 ToPort : 5432 IpProtocol : 'tcp' RDSForRedash : Type : 'AWS::RDS::DBInstance' Properties : Engine : 'postgres' EngineVersion : '9.6' AutoMinorVersionUpgrade : true DBInstanceClass : 'db.t2.micro' DBParameterGroupName : !Ref RDSDBParameterGroupForRedash BackupRetentionPeriod : 7 # バックアップの保持期間 StorageType : 'gp2' AllocatedStorage : 20 # ストレージのサイズ(GB) MultiAZ : false AvailabilityZone : !Ref AZ1 # 予め定義しておく PubliclyAccessible : false DBSubnetGroupName : !Ref RDSDBSubnetGroupNameForRedash VPCSecurityGroups : - !Ref EC2SecurityGroupRDSRedash MasterUsername : !Ref RDSForRedashMasterUsername MasterUserPassword : !Ref RDSForRedashMasterUserPassword PreferredBackupWindow : '15:00-17:00' # UTC PreferredMaintenanceWindow : 'Sat:17:00-Sat:19:00' # UTC ## Redis ElastiCacheSubnetGroupForRedash : Type : 'AWS::ElastiCache::SubnetGroup' Properties : CacheSubnetGroupName : redash-redis-subnet-group Description : 'redis subnet group for redash' SubnetIds : - !Ref EC2SubnetApplicationPrivateAZ1 - !Ref EC2SubnetApplicationPrivateAZ2 EC2SecurityGroupRedashRedis : Type : 'AWS::EC2::SecurityGroup' Properties : GroupName : redash-redis-security-group GroupDescription : 'redis security group for redash' VpcId : !Ref EC2VPC SecurityGroupIngress : - SourceSecurityGroupId : !Ref EC2SecurityGroupECSRedash FromPort : 6379 ToPort : 6379 IpProtocol : 'tcp' ElastiCacheParameterGroupForRedash : Type : 'AWS::ElastiCache::ParameterGroup' Properties : CacheParameterGroupFamily : 'redis4.0' Description : 'Redash Redis' ElasticacheClusterForRedash : Type : 'AWS::ElastiCache::CacheCluster' Properties : ClusterName : 'redash-redis' Engine : 'redis' EngineVersion : '4.0.10' AutoMinorVersionUpgrade : true CacheNodeType : 'cache.t2.micro' NumCacheNodes : 1 CacheParameterGroupName : !Ref ElastiCacheParameterGroupForRedash PreferredAvailabilityZone : !Ref AZ1 CacheSubnetGroupName : !Ref ElastiCacheSubnetGroupForRedash VpcSecurityGroupIds : - !GetAtt EC2SecurityGroupRedashRedis.GroupId Port : 6379 ECS/Fargate 次にECS /FargateでRedashをホスティングする部分を説明します。 今回は以下のようにサービスを分割しました。 Redash Server Redash Worker Puredata Gateway PuredataGatewayはPy4JでPythonとJavaの間を取り持つコンテナなので、分離されているのは自然です。 一方でRedash系の2つが分離されているのは違和感ある人がいるかもしてないので、理由を説明します。 Redash ServerはRedashのweb UIをホスティングしているwebサーバーで、このサービスが直接クエリの実行することはありません。 クエリの実行を担うのはRedash Workerの方です。 これらの間は非同期ジョブライブラリの Celery によってクエリのやり取りが行われています。 なお、Celeryによって作られるジョブキューの実体はRedisのリストです。 そしてクエリの実行結果はPostgreSQLに書き込まれ、それがRedash Serverによって読み出されグラフィカルに表示されます。 クエリの個数が多くなった時にRedash Workerのスケーリングが必要です。 ですので、Redash ServerとRedash Workerの分離を行いました。 今回はECSサービスを3つ作りましたが、まずはRedash ServerとRedash Workerのサービス定義を説明します。 特に注意が必要なポイントは以下の2点で、それぞれ後で説明します。 Redashの待受ポートが5100なこと puredata-gateway.redash.internalというドメインでRedash WorkerがPuredata Gatewayに接続すること Resources : ## ECS ECSClusterForRedash : Type : 'AWS::ECS::Cluster' Properties : ClusterName : redash IAMRoleForRedashTaskExecution : Type : 'AWS::IAM::Role' Properties : AssumeRolePolicyDocument : Version : '2012-10-17' Statement : - Effect : 'Allow' Principal : Service : 'ecs-tasks.amazonaws.com' Action : 'sts:AssumeRole' ManagedPolicyArns : - 'arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy' IAMServiceLinkedRoleForECSRedashService : Type : 'AWS::IAM::ServiceLinkedRole' Properties : AWSServiceName : 'ecs.amazonaws.com' Description : 'Role to enable Amazon ECS to manage your cluster.' ECSTaskDefinitionApplication : Type : 'AWS::ECS::TaskDefinition' Properties : Family : redash-server RequiresCompatibilities : - 'FARGATE' Cpu : 1024 Memory : 2048 NetworkMode : 'awsvpc' ExecutionRoleArn : !GetAtt IAMRoleForRedashTaskExecution.Arn ContainerDefinitions : - Image : !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${ECRRepositoryForRedash}:last Name : 'redash-server' Command : - 'server' Environment : - Name : 'PYTHONUNBUFFERED' Value : '0' - Name : 'REDASH_LOG_LEVEL' Value : 'INFO' - Name : 'REDASH_REDIS_URL' Value : !Sub redis://${ElasticacheClusterForRedash.RedisEndpoint.Address}:${ElasticacheClusterForRedash.RedisEndpoint.Port}/0 - Name : 'REDASH_DATABASE_URL' Value : !Sub postgresql://redash:${RDSRedashUserPassword}@${RDSForRedash.Endpoint.Address}/redash # Redash用のRDSユーザーを予め作っておく - Name : 'REDASH_HOST' Value : '' - Name : 'REDASH_WEB_PORT' # Redashが待ち受けているポート番号 デフォルトの5000ではない理由は後述 Value : '5100' - Name : 'REDASH_ALLOW_SCRIPTS_IN_USER_INPUT' Value : 'true' - Name : 'REDASH_DATE_FORMAT' Value : 'YY/MM/DD' - Name : 'REDASH_ADDITIONAL_QUERY_RUNNERS' # Redashに新しいquery runnerを登録するため Value : 'redash.query_runner.puredata' - Name : 'REDASH_JAVA_GATEWAY_HOST' # このドメインはRoute53のAutoNamingで提供される Value : puredata-gateway.redash.internal Cpu : 1024 Memory : 2048 PortMappings : - ContainerPort : 5100 HostPort : 5100 Protocol : 'tcp' LogConfiguration : LogDriver : 'awslogs' Options : awslogs-group : !Ref LogsLogGroupForRedash # 予め作っておく awslogs-region : !Ref AWS::Region awslogs-stream-prefix : 'server' ECSTaskDefinitionWorker : Type : 'AWS::ECS::TaskDefinition' Properties : Family : redash-worker RequiresCompatibilities : - 'FARGATE' Cpu : 1024 Memory : 2048 NetworkMode : 'awsvpc' ExecutionRoleArn : !GetAtt IAMRoleForRedashTaskExecution.Arn ContainerDefinitions : - Image : !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${ECRRepositoryForRedash}:${RedashGithubSHA1} Name : 'redash-worker' Command : - 'scheduler' Environment : - Name : 'PYTHONUNBUFFERED' Value : '0' - Name : 'REDASH_LOG_LEVEL' Value : 'DEBUG' - Name : 'REDASH_REDIS_URL' Value : !Sub redis://${ElasticacheClusterForRedash.RedisEndpoint.Address}:${ElasticacheClusterForRedash.RedisEndpoint.Port}/0 - Name : 'REDASH_DATABASE_URL' Value : !Sub postgresql://redash:${RDSRedashUserPassword}@${RDSForRedash.Endpoint.Address}/redash - Name : 'QUEUES' Value : 'queries,scheduled_queries,celery' - Name : 'WORKERS_COUNT' Value : '10' - Name : 'REDASH_ADDITIONAL_QUERY_RUNNERS' Value : 'redash.query_runner.puredata' - Name : 'REDASH_JAVA_GATEWAY_HOST' Value : !Sub puredata-gateway.redash.internal Cpu : 1024 Memory : 2048 LogConfiguration : LogDriver : 'awslogs' Options : awslogs-group : !Ref LogsLogGroupForRedash awslogs-region : !Ref AWS::Region awslogs-stream-prefix : 'worker' EC2SecurityGroupECSRedash : Type : 'AWS::EC2::SecurityGroup' Properties : GroupName : redash-ecs-security-group GroupDescription : 'ecs security group for redash' VpcId : !Ref EC2VPC SecurityGroupIngress : - SourceSecurityGroupId : !Ref EC2SecurityGroupALBExternalRedash FromPort : 5100 ToPort : 5100 IpProtocol : 'tcp' ECSServiceRedash : Type : 'AWS::ECS::Service' DependsOn : - IAMServiceLinkedRoleForECSRedashService - ECSServicePuredataGateway Properties : Cluster : !Ref ECSClusterForRedash DesiredCount : 1 LaunchType : 'FARGATE' LoadBalancers : - ContainerName : 'redash-server' ContainerPort : 5100 TargetGroupArn : !Ref ElasticLoadBalancingV2TargetGroupExternalRedash NetworkConfiguration : AwsvpcConfiguration : AssignPublicIp : 'DISABLED' SecurityGroups : - !Ref EC2SecurityGroupECSRedash Subnets : - !Ref EC2SubnetApplicationPrivateAZ1 - !Ref EC2SubnetApplicationPrivateAZ2 PlatformVersion : '1.2.0' TaskDefinition : !Ref ECSTaskDefinitionApplication ECSServiceRedashWorker : Type : 'AWS::ECS::Service' DependsOn : - IAMServiceLinkedRoleForECSRedashService - ECSServicePuredataGateway Properties : Cluster : !Ref ECSClusterForRedash DesiredCount : 3 LaunchType : 'FARGATE' NetworkConfiguration : AwsvpcConfiguration : AssignPublicIp : 'DISABLED' SecurityGroups : - !Ref EC2SecurityGroupECSRedash Subnets : - !Ref EC2SubnetApplicationPrivateAZ1 - !Ref EC2SubnetApplicationPrivateAZ2 PlatformVersion : '1.2.0' TaskDefinition : !Ref ECSTaskDefinitionWorker 次にPuredata Gatewayのサービス定義を示します。 基本的にはRedashのサービス定義と変わりませんが、ServiceDiscoveryに関する設定が追加されているのが特徴です。 前述したRedashサービスから接続をしていたpuredata-gatewat.redash.internalのサービスディスカバリはここで行われます。 まず AWS::ServiceDiscovery::PrivateDnsNamespace リソースによって、 puredata-gateway.redash.internal というHostedZoneがRoute53に作られます。 そして AWS::ServiceDiscovery::Service リソースによって、そのHostedZoneの中にマルチバリューAレコードが作られます。 最後に AWS::ECS::Service リソースのServiceRegistriesプロパティを指定します。 これによって、タスクの起動終了のタイミングでAレコードの値が自動的に書き換わります。 https://docs.aws.amazon.com/Route53/latest/APIReference/overview-service-discovery.html Resources : ServiceDiscoveryPrivateDnsNamespaceForPuredataGateway : Type : "AWS::ServiceDiscovery::PrivateDnsNamespace" Properties : Vpc : !Ref EC2VPC Name : puredata-gateway.redash.internal ServiceDiscoveryServiceForPuredataGateway : Type : "AWS::ServiceDiscovery::Service" Properties : Name : puredata-gateway DnsConfig : NamespaceId : !Ref ServiceDiscoveryPrivateDnsNamespaceForPuredataGateway DnsRecords : - Type : 'A' TTL : 60 HealthCheckCustomConfig : FailureThreshold : 2 ECSTaskDefinitionPuredataGateway : Type : 'AWS::ECS::TaskDefinition' Properties : Family : puredata-gateway RequiresCompatibilities : - 'FARGATE' Cpu : 1024 Memory : 2048 NetworkMode : 'awsvpc' ExecutionRoleArn : !GetAtt IAMRoleForRedashTaskExecution.Arn ContainerDefinitions : - Image : !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${ECRRepositoryForPuredataGateway} Name : 'puredata-gateway' Command : [ 'command' , 'to' , 'start' , 'puregata gateway' ] Cpu : 1024 Memory : 2048 PortMappings : - ContainerPort : 25333 HostPort : 25333 Protocol : 'tcp' LogConfiguration : LogDriver : 'awslogs' Options : awslogs-group : !Ref LogsLogGroupForRedash awslogs-region : !Ref AWS::Region awslogs-stream-prefix : 'puredata-gateway' EC2SecurityGroupECSPuredataGateway : Type : 'AWS::EC2::SecurityGroup' Properties : GroupName : puredata-gateway-ecs-security-group GroupDescription : 'ecs security group for puredata gateway' VpcId : !Ref EC2VPC SecurityGroupIngress : - CidrIp : !Ref ApplicationPrivateCidrBlockAZ1 FromPort : 25333 ToPort : 25333 IpProtocol : 'tcp' - CidrIp : !Ref ApplicationPrivateCidrBlockAZ2 FromPort : 25333 ToPort : 25333 IpProtocol : 'tcp' ECSServicePuredataGateway : Type : 'AWS::ECS::Service' DependsOn : IAMServiceLinkedRoleForECSRedashService Properties : Cluster : !Ref ECSClusterForRedash DesiredCount : 1 LaunchType : 'FARGATE' ServiceRegistries : - RegistryArn : !GetAtt ServiceDiscoveryServiceForPuredataGateway.Arn NetworkConfiguration : AwsvpcConfiguration : AssignPublicIp : 'DISABLED' SecurityGroups : - !Ref EC2SecurityGroupECSPuredataGateway Subnets : - !Ref EC2SubnetApplicationPrivateAZ1 - !Ref EC2SubnetApplicationPrivateAZ2 PlatformVersion : '1.2.0' TaskDefinition : !Ref ECSTaskDefinitionPuredataGateway Redashをawsに構築するにあたって、これ以外にもALB、ACM、Route53なども使用しましたが、記事が長くなってしまうのでここでは割愛します。 Datadog これらのコンテナのメトリクスの監視にはDatadogを使用しています。 Datadogでメトリクスを収集するためには、Datadogのコンテナをサイドカーコンテナとして配置します。 例えば、Redash Serverのコンテナのメトリクスを収集したい場合は、以下のようにコンテナを配置します。 環境変数ECS_FARGATEを true に指定するだけで、そのタスクに含まれるすべてのコンテナのメトリクスを収集してくれます。 Resources : ECSTaskDefinitionApplication : Type : 'AWS::ECS::TaskDefinition' Properties : ContainerDefinitions : - Image : !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${ECRRepositoryForRedash}:last Name : 'redash-server' - Image : datadog/agent:latest Name : 'datadog' Cpu : 256 Memory : 512 Environment : - Name : 'DD_API_KEY' Value : !Ref DatadogAPIKey - Name : 'ECS_FARGATE' Value : 'true' LogConfiguration : LogDriver : 'awslogs' Options : awslogs-group : !Ref LogsLogGroupForRedash awslogs-region : !Ref AWS::Region awslogs-stream-prefix : 'redash-datadog' https://www.datadoghq.com/blog/monitor-aws-fargate/ Fargateの利点欠点 FargateでRedashを構築する最中に感じた、Fargateの利点欠点などをまとめます。 利点 EC2の管理から解放される まず真っ先に思い浮かぶFargateの利点はEC2を管理する必要がないということです。 ECS on EC2の構築をするためにはEC2インスタンスを立ち上げ、そこにECSエージェントをインストールする必要があります。 Fargateを使うことによって、そのような一手間をかけること無く、いきなりコンテナをデプロイできるので便利です。 コンテナ数のスケーリングをするときにEC2のスケーリングをしなくても良い 前述したことと少し関連しますが、EC2の管理から解放されたことでスケーリングの時に考慮する必要のある要素が減りました。 スケーリングをするときにはサービスのタスク数だけを変化させればよく、従来のECS on EC2で考える必要のあったEC2インスタンスのスケーリングは不要です。 AutoNamingによるサービスディスカバリは便利 システムをマイクロサービス化するときにサービスディスカバリの仕組みはほぼ必須です。 Route53のAutoNamingを使うとDNSレベルでのサービスディスカバリができます。 なお、これはFargateの利点というよりもECSの利点です。 欠点 コンテナのデプロイが遅い Fargateを使った時にはコンテナのデプロイには数分かかってしまいます。 そのため、高速なスケールアウトを期待してFargateを使うとがっかりすることがあるかと思います。 同一タスク中の複数のプロセスが同じポートで待受できない Fargateでは同一タスクに属するコンテナ間の通信をさせるためにはlocalhostを使います。 そのため、同一タスクに属する複数のプロセスが同じポート番号で待受しようとすると、後から待受した方が失敗します。 実際にRedashとDatadog Agentの両方が5000番ポートでlistenをしていたため、Redashのサーバーが立ち上がらないという現象が発生しました。 そのためRedashにパッチを当て、5100番ポートで待ち受けるように修正しました。 CloudFormationのテンプレートで5100番ポートを使ってRedashの待受をしている理由はこれです（伏線回収） ログドライバーがawslogsしか選択できない ECS on EC2の場合はjournaldやfluentdにログを流すことができますが、ECS/Fargateではawslogsドライバーのみがサポートされます。 awslogsドライバーが収集したログはCloudWatchLogsに送られます。 そのため、すでに別のログ収集基盤がある場合には、CloudWatchLogsからそちらにログを流す必要があります。 https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html previllegeモードでDockerを動かすことができない これは些細な欠点ですが、privilegeモードでDockerを動かすことができないので、例えばDocker in Dockerのような構成にすることはできません。 まとめ 社内PCでホスティングされていたRedashをawsに移すことによって、Redashの動作に必要なコンポーネントをすべてフルマネージドにできました。 さらにこの設定はすべてCloudFormationで管理されています。 そのため、他のチームがawsにRedashを構築したくなったときにはテンプレートファイルを渡すことで同等の構成を簡単に作ることが出来るようになりました。 弊社ではZOZOTOWNの売上を支えているMarketingAutomationに興味がある方、クラウドを活用して既存の運用を改善することに興味がある方を募集しています。 興味のある方はぜひ以下のリンクからご応募ください。 www.wantedly.com

こんにちは。ZOZO研究所 福岡の光瀬です。Pythonを書かれている皆様は、普段どのように開発をすすめていますか？　pipとvenv/virtualenvによるこれまでのデファクトの組み合わせだけではなく、最近は Pipenv を使用している開発者も増えてきたのではないでしょうか。 日々の検証や開発を効率よく進めるにあたって、依存関係を適切かつ楽に管理するのはとても重要だと感じていて、ここ半年ほどPipenvを利用しています。 今回は、その中でsetup.pyやrequirements.txtそしてPipfileの住み分け・運用について考えたことをまとめてみました。 TL;DR Pipenvが使えることで、確かに楽になった部分はあるのかなと思っています。 一方で、既存のツールとの兼ね合いがまだ微妙な部分もあります。 その上で、以下の運用がベターなのかなと考えました。 Pipenvのみで完結させようとしない（setup.pyの install_requires を併用する） setup.pyの install_requires には、直接の依存関係をゆるく記述し pipenv install -e でPipenv管理下に置く 開発・テストに必要な依存関係をPipfileの dev-packages へ記述する 依存関係のロックが必要であればrequirements.txtではなくPipfile.lockを使用する Pipenvとは何か Pipenv は、一言でいえば pipとvirtualenvをラップして、依存関係を　 Pipfile およびPipfile.lockで管理するツール です。 いわゆるRubyにおけるbundlerやNode.jsにおけるnpmあるいはyarnのような立ち位置ですね。 今やごく当たり前になっているであろう開発フローをPythonにおいても実現できます。 例えば、以下に列挙する機能が実装されています。 Pipfileによる依存関係の管理 Pipfileによる開発用の依存関係の管理 Pipfile.lockによる依存関係のロック virtualenv環境の自動構築 Pipfileで指定された python_version と現在のバージョンとのチェック Pipfileで指定された python_version の処理系の自動インストール（pyenvが利用可能な時のみ） ..。など より詳しくは 公式ドキュメント をどうぞ。なお、Pipenvには 日本語ドキュメント もあります。また、 作者のKenneth Reitz氏のPyCon 2018におけるスライド もオススメです。 Pipenv以前の話 pipおよびvenv/virtualenvによる開発フロー Pythonを書かれている皆様は、普段どのように開発をすすめられていますでしょうか？　Pipenv以前、私は以下のようなフローで開発していました。 使用したいバージョンの処理系をインストールする venv/virtualenvでプロジェクト用の環境を切る 「使用したいライブラリ」をsetup.pyの install_requires に列挙して pip install -e . でインストールする テスト時に利用する依存関係はsetup.pyの test_requires に列挙する pip freeze でrequirements.txtを吐きだしておく（ライブラリではない、依存関係の終端であるプリケーションの場合） 一見、特に問題がないように見えますが、 開発時に必要な依存関係の管理方法が明確ではない のが1つの問題なのかなと思います。 例えば、静的型チェッカーである mypy を使って、編集しながら型チェックをしていきたい場合があります。 この場合、mypyはどこに依存関係として記述するのが適当でしょうか？ 実際にアプリケーション・ライブラリが利用される際には、通常不要なツールです。 そのため、少なくとも install_requires に書くのは適当でなさそうです。 一方、テスト時にのみ使用できれば良いということではないので test_requires に書くのも違うように思えます。 開発時に必要な依存関係の管理に対するワークアラウンド 開発時に必要な依存関係の管理については、明確な答えはないものの、いくつかのワークアラウンドで対処されてきたようです。 setup.pyの extras_require を利用してオプショナルな依存関係として扱う requirements.txtに加えて、開発用に別途requirements-dev.txtを用意して pip install -r requirements-dev.txt する いずれの場合も、 pip freeze した際に開発用の依存関係がrequirements.txtへ混入します。 requirements.txtを依存関係のロックとして扱いたい場合に、余計なパッケージが含まれるのはあまり嬉しくありません。 Pipenvが解決した問題 開発・テスト用の依存関係の管理 Pipfileには、開発・テスト用の依存関係が記述・記録される専用の dev-packages というテーブルがあります。 コマンドラインからは、 pipenv install --dev {package_name} でインストール・Pipfileへ記録できます。 Pipfile.lockには開発用の依存関係も記録されますが、 pipenv install 時に --dev を付与した場合のみインストールされます。 pipやvirtualenvなど各種ツールの隠蔽 環境構築について、pipやvirtualenvそしてpyenvを直接さわらずとも環境がつくれるようになっています。 既存ツールをラップしながら、他の言語で提供されているツールと同等の機能を提供している点は、地味ながらもひとつの利点です。 少なくとも優れたパッケージ管理ツールを備えた他の言語のユーザーがPythonを触る際の驚きは減るはずです。 Pipenvが解決できていない問題 依存関係上の終端になるようなアプリケーションであれば、setup.pyを用意せずPipenvのみで開発を進められるように思います。 ただし、pipはPipfileを読まないため、ライブラリの場合には、Pipenvのみでは完結しません。 直接pipからインストールされるライブラリが大半であると思われる現状、ライブラリの開発においてはsetup.pyを書かざるをえなくなっています。 結局どのように運用するのが楽なのか Pipenvの公式の見解が Pipfile vs Setup.py に書かれています。 他のコードから参照される「ライブラリ」であればsetup.pyでまず管理すべきで、どこからも参照されない「アプリケーション」であればPipfileで依存関係を管理するのが良いという話ですね。 この公式の見解を踏まえつつ、ライブラリ・アプリケーションの区別をせずに同じフローへ落とすのが楽なのかなと考えました。 pipからインストール可能にするため、 install_requires を使用する 不要になったパッケージを排除しやすくするため、 pipenv install -e でプロジェクトのパッケージをインストールし、依存関係はPipenv管理下に置く 開発・テスト時にのみ必要なパッケージはsetup.pyに入っている必要はないので、Pipfileに書く 依存関係のロックが必要でない場合は、 pipenv install をする際に --skip-lock するのが適当かと考えています。 もちろん、ライブラリの開発の場合は、setup.pyだけで最低限管理できます。 とはいえほとんどの場合、開発時にのみ使用するツールが入ってきますし、どのみちvenv/virtualenv環境もつくります。 そのため、初めからPipenv管理下に置いてしまった方が楽な印象です。 まとめ：Pipenvは依存関係の管理を楽にしたのか 依存関係の管理については、方法にブレが減ったという意味では楽になったと感じます。 加えて、pipとvirtualenvのラッパーとして振る舞うので、特に意識しなくとも他プロジェクトの環境と分離して管理できるのも良い点です。 一方で、pipはPipfileおよびPipfile.lockを参照できないため、「便利ではあるけど既存ツールを完全に置き換えたものではない」というのが現状のように思います。 基本はsetup.pyを書くという前提で、Pipfileを併用していこうと考えています。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください。 www.wantedly.com

こんにちは。バックエンドエンジニアの田島( @katsuyan121 )です。 弊社ではデータマートをBigQuery上に構築しています。データマートはデータベース全体のデータのうち、必要なデータだけを使いやすい形にしたデータベースです。データマート作成のためのSQLクエリは日々更新や追加があり、BigQueryのコンソールから自由にデータマートを作ってしまうと管理が大変になってしまいます。 そこで、データマートをすべてGitHub上でバージョン管理し、運用の効率化をしました。また、差分更新の導入や依存関係のあるデータマートへの対応などのデータマート構築に必要な機能を作成しました。 弊社のデータ基盤をざっくり紹介します。まずデータはBigQueryへ集約し、Digdagを用いてデータ基盤を構築しています。以下がその概要図です。S3などの分散ストレージや各種DBからデータをBigQueryへ同期し、BigQuery内部でデータマートを構築します。本ブログではこのうちのデータマート構築について紹介します。 BigQueryでのデータマートの実現方法 データマートをBigQuery上に構築していると紹介しましたがその実態は以下の2つです。 BigQueryのView BigQueryのTable 計算コストが小さいマートに関しては View を用いることでデータの鮮度を保つようにします。逆に計算コストの高いマートは事前に集計などの計算をし Table として保持することで、参照時にコストの高い計算しなくて済むようにしています。 データマート構築の問題点 冒頭でもいくつか紹介しましたがデータマートの構築には以下のような問題が存在します。 データマートは日々更新や追加がされる 現在弊社のデータマートの Table View の数は100を超えており、今でも日々追加されている データマートをBigQueryのWebコンソールから自由に作ってしまうと管理が大変 誰が作ったのかわからない 一時的に作ったデータマートなどがどこから参照されているかわからない 溜まってしまったデータマートがどこから参照されているかわからないので不用意に消せない またテーブルを用いてデータマートを構築する場合以下のことが問題となります。 更新に時間がかかる データマートがどういったクエリにより作られたかわからない 定期的にテーブルを更新する必要がある データマートの Table View が他の Table View を参照している場合、更新する順番を間違えるとデータに不整合が生じる そこで、これらの問題を解決するためのシステムを作成しました。 データマートのクエリをGitHubで管理する BigQueryのViewやTableはBigQueryのWebコンソール画面から簡単に作ることができます。しかしそれでは誰が作ったマートなのかなのかが簡単には分からないなどの運用の問題が生じてしまうと紹介しました。そこでSQLファイルを作成し、それらをAPIからBigQueryに反映をします。実際にはRubyの Google Cloud SDK を利用して反映を行っています。 また、SQLファイルのファイル名を View または Table の名前にすることで、実際のマートとSQLファイルとの対応関係が簡単にわかります。以下がその概要です。 Before After マート作成方法 BigQueryのコンソールから手動で作成 SQLファイルをGit管理しAPI経由で作成 以下に View Table をデータマートへ反映する方法を示しますが、全てのマートをSELECT文のSQLファイルとして表現できます。 BigQueryにSQLを反映する仕組みを作ったことで、すべてのマートをSQLファイルとしてGit管理できるようになりました。 Viewのマート反映 View のマートに関しては作成したSQLをそのままBigQueryに反映します。 新規作成の場合 require ' google/cloud/bigquery ' sql = File .read( ' テーブル名.sql ' ) bq_client = Google :: Cloud :: Bigquery .new( project : ' project ' , credentials : ' path ' ) dataset = bq_clent.dataset( ' データセット名 ' ) dataset.create_view( ' ビューの名前 ' , sql, standard_sql : true ) 更新の場合 require ' google/cloud/bigquery ' bq_client = Google :: Cloud :: Bigquery .new( project : ' project ' , credentials : ' path ' ) sql = File .read( ' テーブル名.sql ' ) dataset = bq_clent.dataset( ' データセット名 ' ) view = dataset.table( ' テーブル名) view.set_query(sql, standard_sql: true) テーブルのマート反映 テーブルのマートについてはBigQueryの Destination Table という機能を使うことで、SELECT文の結果をそのままテーブルに反映できます。 以下のようなコードを実行することでBigQueryにSELECT文の結果がテーブルとして作成されます。この処理は、BigQueryによってアトミックにテーブルが作成されます。 require ' google/cloud/bigquery ' bq_client = Google :: Cloud :: Bigquery .new( project : ' project ' , credentials : ' path ' ) sql = File .read( ' テーブル名.sql ' ) job = bq_client.query_job(sql, standart_sql : true , table : ' テーブル名 ' , write : ' truncate ' , create : ' needed ' ) job.wait_until_done! 差分更新 計算コストの高いマートは事前に集計などの計算をし Table として保持すると紹介しました。しかし集計するデータが大きすぎる場合、毎回全量のデータを集計・更新すると時間がかかりすぎてしまいます。 例えば日付ごとに集計するテーブルの場合、毎日全量のデータを集計し直していると最新の日付以外の集計処理は前日と同じ計算をしてしまうことになり集計処理が増えて行きます。そこで差分更新をすることでこの問題を解決します。 本システムでは差分更新にappendとoverwriteの2種類を行っています。 append appendは集計した結果を既存のテーブルに対してinsertします。 以下のようなテンプレートに対しSQLファイルの中身をそのまま埋め込むことで、「テーブルのマート反映までの流れ」で紹介した処理と同じようにBigQueryに反映できます。 SELECT * FROM `既存のテーブル` union all ( <%= sql %> ) overwrite 一部集計した結果を既存のマートに上書きしなければならない場合appendだけでは対応できません。overwriteの処理ではそのようなケースに対応するため pk などのユニークキーを利用して集計結果をマージします。 こちらもappendのときと同じように以下のようなテンプレートに対してSQLを埋め込みBigQueryに反映します。 SELECT * except(priority, row_number) FROM ( SELECT *, row_number() over (partition by <%= pk %> order by priority) as row_number FROM ( SELECT *, 1 AS priority FROM ( <%= sql %> ) union all SELECT *, 2 FROM `既存のテーブル` ) ) WHERE row_number = 1 以上のように差分更新する対象のテーブルは統一した方法で差分更新が行われるようになりました。 append更新の改善 最初は以上のようにappendとoverwriteの処理を通常の更新処理と同じように行っていました。しかし運用しているうちに SELECT * FROM により全件のデータを毎回取得していることが以下の2点で問題になりました。 処理に時間がかかる BigQueryはクエリの使用量に対して課金されるためお金がかかってしまう そこでBigQueryの append の機能を利用するように変更しました。この、 append によるデータの追記もBigQueryによりアトミックに行われることが保証されています。以下のコードで、それを実現しています。 require ' google/cloud/bigquery ' bq_client = Google :: Cloud :: Bigquery .new( project : ' project ' , credentials : ' path ' ) sql = File .read( ' テーブル名.sql ' ) job = bq_client.query_job(sql, standard_sql : true , table : ' テーブル名 ' , write : ' append ' , create : ' needed ' ) job.wait_until_done! これにより、 SELECT * FROM の処理をなくすことに成功しました。ただし、overwriteは以上の解決策は適用できないため上で紹介した通りに今も更新を行っており、課題となっています。 冪等性の担保 差分更新の仕組みを紹介しましたが、差分更新の処理があると何かの問題で処理を再実行した場合データが重複するといったデータの整合性に対する問題が生じてしまいます。 例えば、既存のテーブルに対して append の処理をします。その後再実行したい場合、もう一度 append の処理を行うと append により追加されたデータが重複してしまいます。 そこで、以下のようにすることで冪等性を担保し、何回同じ処理をしても同じ結果になるよう工夫しました。 また、 overwrite でも同じように処理を行います。 マート更新時に、マートと同じデータを保持したバックアップを作成します。そして、差分更新を行う場合はバックアップに対して差分更新を行い、その結果を実際のマートに反映します。 2018-01-06 にマートを更新すると以下のような処理になります。 これをコードにしたものが以下になります。 require ' google/cloud/bigquery ' bq_client = Google :: Cloud :: Bigquery .new( project : ' project ' , credentials : ' path ' ) dataset = bq_clent.dataset( ' データセット名 ' ) table = dataset.table( ' mart_table ' , skip_lookup : true ) backup_table_yesterday = dataset.table( ' mart_table_20180105 ' , skip_lookup : true ) backup_table_today = dataset.table( ' mart_table_20180106 ' , skip_lookup : true ) backup_table.copy_job(destination_table, create : ' needed ' , write : ' truncate ' ) # バックアップテーブルを実際のテーブルにコピー job = bq_client.query_job(sql, standard_sql : true , table : table, write : ' append ' , create : ' needed ' , &job_configuration) job.wait_until_done! raise " Fail BigQuery job: #{ job.error }" if job.failed? table.copy_job( ' バックアップテーブル.sql ' , create : ' needed ' , write : ' truncate ' ) # 更新されたテーブルをバックアップ 以上のように差分更新をすることで、何回リトライしてもデータの整合性が保たれるうようになりました。 マートの依存関係 マートが他のマートを参照している場合、更新する順番を間違えるとデータに不整合が生じると紹介しました。例えば existing_table1 existing_table2 のテーブルが存在するとし、以下のような4つのマート構築を考えます。その場合、「table3の前にtable1」「table4の前にtable1とtable3」が更新されている必要があります。 table1.sql SELECT * FROM `project.dataset.existing_table1`; table2.sql SELECT * FROM `project.dataset.xisting_table2`; table3.sql SELECT * FROM `project.dataset.table2`; table4.sql SELECT * FROM `project.dataset.table1` UNION ALL SELECT * FROM `project.dataset.table4`; そこで以下のようなグラフを作成し、実行順を確認します。このグラフは、SQLの FROM または JOIN の後ろのテーブル名とSQLファイル名を利用します。FROMの後ろに書かれているテーブルはSQLファイル名のマートよりも前に実行しなければなりません。そのため「FROMの後ろのテーブル名」->「SQLファイルのファイル名」というグラフを作成します。 例えば上の4つのSQLからマートのグラフを作成すると以下のようになります。 以下のようなコードでグラフを生成します。 graph = {} sql_files = [table1.sql, table2.sql, table3.sql, table4.sql] sql_files.each do | sql_file | sql_file_table_name = sql_file.split( ' . ' ).first sql = File .open(sql_file, ' rt:UTF-8 ' ) { | file | file.read.chomp } related_tables = sql.scan( /(?: FROM | JOIN )[\s \n]+ ` (.+?) ` /i ) graph[sql_file_table_name] = related_tables.map do | str | _, table = str.first.split( ' . ' ) next if table == sql_file_table_name # 自己参照は除外 table end .compact end この結果に対してマート以外のテーブルを削除すると、以下のような結果になります。 [ { ' table3 ' => [ ' table2 ' ]}, { ' table4 ' => [ ' table1 ' , ' table3 ' ]} ] 並列実行 以上のグラフを利用することで、マート作成のクエリの実行の順番を担保したまま並列化できます。並列実行を簡易化するために以上のようなグラフを、以下のようなテーブルのリストのリストに変換します。各テーブルのリストは先頭から順番に実行でき、テーブルのリストの中身はそれぞれ並列実行することが可能になります。 [[table1, table2], [table3], [table4]] この変換は、まず親ノードがないテーブル一覧をリストに追加します。そして追加したテーブルをグラフから削除し、もう一度親ノードがないテーブル一覧をリストに追加します。これを繰り返すことで、以上のようなリストが生成されます。 以下のようなコードでグラフからリストを生成します。 def sort_tables (graph) graph = graph.dup result = [] until graph.empty? nodes = graph.keys.select { | node | graph[node].empty? } result << nodes raise ' cyclic path detected! ' if nodes.empty? nodes.each { | node | graph.delete(node) } graph.transform_values! { | v | v - nodes } end return result end このリストを利用し、最初に「table1, table2」続いて「table3」最後に「table4」を実行します。 並列実行はDigdagで実現しており、以下のようなconfigファイルになっています。 +set_refresh_views: call> set_refresh_views # REFRESH_TABLESESにテーブルのリストのリストを格納 +update_views: for_each>: REFRESH_TABLES: ${REFRESH_TABLESES} _parallel: false _do: for_each>: REFRESH_TABLE: ${REFRESH_TABLES} _parallel: true # ここをtrueにすることで並列実行を実現 _do: _retry: 3 call> refresh # 実際にマートを更新する処理 以上のように実行する順番を考える必要があった所を、システムにより自動解決することに成功しました。さらに、並列実行をすることで更新スピードの短縮にも成功しました。 このシステムを作ってどうなったか 最後に本システムによりデータマートの運用に関してどのようになったか紹介します。 GitHubでマート管理できるようになり日々追加されるマートの管理を統一したルールで管理できるようになった 差分更新や並列実行を導入したことで、データマートの更新の時間短縮に成功した データマートのすべてのクエリをGitHubで参照できるようになった システムを定期的に実行することでテーブルの更新が自動化された データマート同士の参照が自動解決されるようになった 以上のように冒頭に挙げた問題を解決することに成功しました。またその他に以下のようなメリットが見られました。 冪等性の担保をしたことで、マート更新の再実行を気軽にできるようになった マートのSQLをGitHubで管理することによりコードレビューが活発になった GitHub上でレビューができるため誰でも気軽にマートを追加できるようになった 以上のようにデータ基盤のコード管理とマート管理をGIthubに統一、システム化することで様々なメリットが得られました。 最後に 本文でも紹介しましたが、本システムにはまだまだ問題が残されています。弊社では一緒にデータ基盤を作ってくれる方を大募集しています。 ご興味がある方は以下のリンクから是非ご応募ください！ www.wantedly.com

こんにちは！ 好きなスシローは 五反田店 なバックエンドエンジニアのりほやん( @rllllho ) です。 9/6,7,8に開催された builderscon tokyo 2018 へ参加しました。 カンファレンスで印象に残ったセッションをいくつかご紹介します。 buildersconとは 公式サイト にはbuildersconについて下記のように説明されています。 buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。buildersconではトークに関して技術的な制約はありません、特定のプログラミング言語や技術スタックによるくくりも設けません。 必要なのは技術者達に刺激を与えワクワクさせてくれるアイデアのみです。 あなたが実装したクレイジーなハックを見せて下さい。あなたの好きな言語のディープな知識をシェアしてください。あなたの直面した様々な問題と、それをどう解決したかを教えてください。未来技術のような未知の領域について教えてください。 記述の通り、プログラミング言語に特化したカンファレンスではなく包括的に様々な技術を扱っているカンファレンスです。 印象に残ったセッション 知らなかった時に困るWebサービスのセキュリティ対策 speakerdeck.com tnmtさんによる カラーミーショップで実際に発生したセキュリティインシデント の実例を元に、どのような攻撃が仕掛けられたのか、どのような対処・再発防止を行ったかについてのお話でした。 上記インシデントの検知は、不正なファイルが置かれたことを検知したのではなく不正なファイルが実行されたことにより発生した負荷アラートがきっかけで発覚したそうです。 またデータベース関連のログが不足しており、データベースへアクセスされた痕跡はあったものの何件抜かれたかなどがわからない状況だったそうです。 インシデントを受けセキュリティ新体制の見直し、WAF、OSコマンドの実行ログ、クエリログを残すなどの対応を行なっているそうです。 webアプリケーションに携わっている身として、セキュリティの問題は絶対避けては通れない問題です。 実際に起こってしまったインシデントに対しての対応や経験など実体験を聞くことができ、とても勉強になりました。 「Webとは何か？」あるいは「WebをWebたらしめるものは何か？」 www.youtube.com Jxckさんによるwebのこれまでの歴史、いまのwebの役割とは何なのか、これからのwebはどうなっていくのかというお話でした。 ティム・バーナーズ＝リーが構想した最初のwebはHypermedia Systemとしてのwebでした。 JavaScriptやiframeなどを使用できるようになりwebによってできることが増え、webはHypemedia Systemからアプリケーションシステムへと役割が変わっていきました。 さらに現在ではwebからデバイスに接続できるようにもなり、Operation System化しているとのことでした。 webはセキュリティモデルと共に進化しているという話が印象的でした。 Ajaxの登場によりJavaScriptがブラウザの意図しない情報を通信できるようになったため、セキュリティモデルとしてoriginが導入され、このoriginというセキュリティモデルがあるおかげでAjaxを正当化できwebのアプリケーション化が進んだそうです。 そのためOS化しようとしている現在のwebのセキュリティモデルであるPermissionの必要性についてお話しされていました。 セキュリティモデルをどのように変化させて策定するかがwebの進化にとても重要であるという話がとても面白かったっです。 ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか speakerdeck.com takihitoさんによるゲームの開発や運用の体制についてのお話でした。 実際にゲームを運用する上で発生した高負荷による障害とその対応について4つ紹介されました。 アプリケーションサーバーに対する高負荷検証は行なってはいたが、ログサーバーが盲点となっておりボトルネックになってしまった話 リリース後にサーバーの負荷が異常に高くなっており確認したところ、Redisのkeysコマンドがアプリケーションで使用されており高負荷になってしまっていた話 大規模な流入施策を行うために検証を行なってはいたが、アプリ申請後に重たいリクエストをアプリから頻繁に叩かれていることに気づきAPIを軽量に研ぎ澄ました話 ガチャによる高負荷によりDBが詰まり緊急メンテナンス、DBのチューニングやアプリケーションコードの修正を行なっても収まらず最終的にはテーブルの設計変更を行った話 ゲームならではの急激な高負荷についてのお話はとても興味深かったです。 高負荷対策のお話の中で、レプリケーション遅延なども考慮しなければいけないためアプリケーションのスケールアップよりDB関連のスケールアップの方が難しいということをおっしゃられていてDB設計の重要さを再確認しました。 RDB THE Right Way 〜壮大なるRDBリファクタリング物語〜 speakerdeck.com soudaiさんによるRDBのリファクタリングについてのお話でした。 アンケートフォームの設計を例に、RDB設計のアンチパターンをご紹介されていてとてもわかりやすかったです。 DBのテーブル設計を行う際に初めからデータの設計やデータストア選定などをしてしまいがちですが、最初にデータ設計をせずにモデリングを正しく行うことがとても重要だそうです。 またテーブルの責務はクラスの責務に似ており、テーブルのスコープを小さくすることを意識した方がよいとのことでした。 データベースの問題はすぐに顕在化するものではなくリリース後忘れた頃に顕在化するという話にはとても共感しました。 プロジェクトに途中から入った際にDB構成を理解する方法として、チームで『テーブル一覧を眺める会』を開催するとよいそうです。 中には誰も知らないテーブルが出てきたりするそうです。さっそくチームでやってみようと思います。 解決した問題の大きさがエンジニアの価値、大きな問題に立ち向かおう。という言葉がとても印象的でした。 自分もエンジニアとして、大きな問題に技術で立ち向かっていきたいです。 ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ speakerdeck.com aerealさんによる、独自ドメインで運用されているはてなブログのHTTPS証明書を配信・発行する仕組みについてのお話でした。 証明書配信に関しては、はてなブログでは万単位の独自ドメインがありリクエストごとに証明書を取得・使用するため低レイテンシであることが求められます。 そのためmemcacheに証明書をキャッシュしデータストアであるDynamoDBへの問い合わせを減らすことで、レイテンシを悪化させずに証明書の配信を行なっているそうです。 証明書発行に関しては、発行リクエストが失敗し続けるとAPIの上限回数を超えてしまうため、失敗した場合に対象から外したり外部API通信のエラーを適切に処理する必要があります。 AWSのStep Functions(SFn)というワークフローサービスとLambdaを組み合わせた仕組みになっているそうです。 DynamoDBへ保存する際に設定するTTLが切れたタイミングでトリガーが発火し証明書を更新するLambda関数が呼び出され、証明書の自動更新を行なっているとのことでした。 データ自身が更新タイミングを持つことにより、更新するLambdaが更新対象を抽出する必要がなくなります。 Lambdaの責任が証明書を更新することだけに切り分けられ、関数がシンプルになるということでした。 ワーフクローエンジンのみがバッチの状態・順番を知っており、関数やクラスは状態を保存せず入力に対し処理を実行し出力するというシンプルな形にすることでバッチの複雑性を排除したそうです。 まとめ DB設計の話や高負荷の話など、私が仕事で使っている身近な技術のお話を聞くことができとても勉強になり、たくさんの『知らなかったことを、聞く』ことができました。 カンファレンスでたくさんの知見を得たので、業務に還元していきたいと思います。 エンジニアが好きな技術や作ったもの、経験したことを熱く喋るお話はとても面白かったです！ 運営の方・ご登壇の方々、素敵なカンファレンスをありがとうございました！ スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ www.wantedly.com

こんにちは。品質管理部エンジニアリングチームの高橋です。 今回は品質管理部として初のTECH BLOG投稿ということもあり、 「品質 / Quality」について掘り下げてみたいと思います。 「品質」の意味 「品質」という言葉の語源は古代ギリシャにまで遡ります。 「万学の祖」と称されるアリストテレスは、物質（Substance）を「量的側面」と「質的側面」に分けて定義しました。 その際に量的な側面を表現する言葉として英語の質量（Quantitiy）に相当するギリシャ語を用いました。 そして対立概念である質的な側面を表現する言葉として、英語のQualityの語源となったラテン語のQualitasを用いたと言われています。 月日は流れ現在、ISO 9000シリーズにて「品質」は「本来備わっている特性の集まりが、要求事項を満たす程度」と述べられています。※ISO 9000シリーズとは、国際標準化機構が定めた品質マネジメントシステムに関する規格の総称です。 『プログラミングの心理学』や『一般システム思考入門』を著した、ソフトウェア開発の人類学者であるジェラルド・ワインバーグは、「品質は誰かにとっての価値である」と自著内で述べています。 またソフトウェアエンジニアリングとしてのソフトウェア「品質」は以下のように定義されています。 (以下、 https://en.wikipedia.org/wiki/Software_quality より引用) In the context of software engineering, software quality refers to two related but distinct notions that exist wherever quality is defined in a business context: →ソフトウェアエンジニアリングにおいて、 ソフトウェア品質 とは、2つの関連しているが、異なる概念が定義される。 ・Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced. →ソフトウェアの 機能品質 は、機能要件または仕様に基づいて、与えられた設計に準拠しているかを指す。その特性はソフトウェアの目的に対する適合度、もしくは市場において競合ソフトと比べてより価値があると判断するための手段とも言うことができ、どれだけ正確にソフトウェアが作られたかの度合いである。 ・Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed. →ソフトウェアの構造的品質とは、堅牢性や保守性などの機能要件の提供をサポートする 非機能要件 を指す。ソフトウェアが必要に応じて動くための数多くの要件がある。 「品質」が良いとは 品質の良さに関して、「立場」から考えてみます。 もし自分が経営者の立場であったならば、最優先するべきは売上げです。 その為、会社として利益の大きいもの＝品質が良いと考えられます。 では経営者ではなく研究者の立場だったらどうでしょう。 研究はそもそも莫大なお金がかかるものであり、研究者が研究中にコストやコストパフォーマンスを優先することはないでしょう。 おそらく研究者の方は、世界に比類ない発見や革新的なものを素晴らしいものと考えるはずです。 経営者　→最大限の利益が出るもの 研究者　→最新のテクノロジーが盛り込まれた革新的なもの 開発者　→要求された機能が実装された、整然としたコードで作成されたもの テスター→仕様書通りに動作する不具合のないもの このように、「品質」の基準は、判断する人の立場によって決定されます。 今度は品質の良さに関して、「物・サービス」から考えてみます。 例えば1万分の1の確率で何らかの不具合が発生する物・サービスの存在を仮定します。 そのサービスが「本の製本」だとしたら。製本ですので、1万冊に1冊の割合で落丁が発生します。 しかし出荷段階で弾いたり、無償で返品対応を行えば、そこまで大きな問題にはならないはずです。 ではそのサービスが「医療機器」だとしたら。 1万台に1台の割合で使用途中に動作が停止してしまうペースメーカーが出荷されたとしたらどうでしょう。 おそらく社会的な問題になるのではないでしょうか。 医療機器に限らず、人の命に関わる物・サービスに関しては、たとえ1万分の1であっても不具合は許されません。 このように、「品質」の基準は、物・サービスの目的によっても変わってきます。 上記のように様々な「品質」の価値基準を一概に定めることは不可能である為、必然的にどこに基準を置くかが重要になってきます。 では品質管理部の一員としての私は、「品質」の基準をどこに定めればよいのでしょうか。 ここでもう1度ジェラルド・ワインバーグの言葉を反芻してみます。 「品質は 誰か にとっての価値である」 この「誰か」とは、「 ユーザー/顧客 」と定義するべきでしょう。 すなわち、「品質」の価値基準は「ユーザー」です。 自社の提供する物・サービスを利用するユーザーの皆さんが、どうすれば便利で・安全に・楽しくサービスを利用できるか考えるのが品質管理部の使命ではないでしょうか。 「品質管理」とは 前項で品質の基準はユーザーに置くべきと述べました。自ずと「品質管理」の指針も見えてくるのではないでしょうか。 ただここで1つ留意しておきたいのが、 品質管理の成功 = ユーザーの満足 品質管理の失敗 = ユーザーの不満足　であるとは必ずしも言えないということです。 1980年代に狩野紀昭によって提唱された、狩野モデルという品質に関するモデルが存在します。 狩野は品質を「当たり前品質」「一元的品質」「魅力的品質」「無関心品質」「逆品質」の5つに分類しました。 そしてその品質がどの品質要素に該当するかによって、顧客満足度に与える効果が異なると提唱しました。 たとえ不具合が残っていたとしても、狩野モデルでいう「無関心品質」に該当する品質の不具合であればユーザー満足度に大きな影響は与えません。 逆に他の「一元的品質」や「魅力的品質」の品質の完成度が高ければ、ユーザーは十分に満足することでしょう。 ただどちらにせよ、品質の基準 = ユーザー の公式は基本的にゆるがないと思っています。 よって、「品質管理」= ユーザーが満足できるサービスが提供されるように導くこと だと私は考えています。 企画→開発→テストの全ての工程において、ユーザーを最優先に考える。そしてそれを継続することではじめて、「品質」が向上していくと思います。 「お客様は神様」という言葉が、接客を伴う業務の際に周知されたりしますよね。 多少オーバーな表現の気もしますが、ユーザーが直接目に見えないソフトウェア開発においても、お客様を第一に考えて業務にあたる姿勢が何よりも大切ではないでしょうか。 おわりに 今回は品質管理部の初投稿ということで、「品質」に関して記事を書かせて頂きました。 記事中でも述べたように、「品質」や「品質管理」に答えはないと思っています。 みなさんの考える「品質」とはなんでしょうか？　ぜひ考えをお聞かせ下さい。 スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください。 www.starttoday-tech.com 参考文献 / クレジット 参考文献 https://en.wikipedia.org/wiki/Software_quality https://ja.wikipedia.org/wiki/ISO_9000 https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB クレジット https://www.flaticon.com/free-icon/check-list_1102560#term=check&page=2&position=54 https://www.flaticon.com/free-icon/medal_1067629#term=quality&page=3&position=22

Kotlin Fest2018参加レポート 福岡研究所の渡辺（しかじろう @shikajiro）です。Kotlinのおっきなイベントが東京で開催されるということで福岡から飛んで✈いきました。 福岡でもFukuoka.ktという名前で過去に2回ほどイベントを主催しており、KotlinFest主催の太郎さんに登壇していただいたこともありました。僕自身3か月ほどKotlinから離れてましたが、直近の技術情報などをフォローできたらいいなと思い参加しました。 KotlinFestとは 2018/08/25（土）に開催された有志による日本最大のKotlinイベントです。 kotlin.connpass.com 「Kotlinを愛でる」をビジョンに、Kotlinに関する知見の共有と、Kotlinファンの交流の場を提供する技術カンファレンスです。 とあるように、Kotlinを愛するKotlinユーザーグループのメンバーにより運営されています。 参加者プレゼント すごい作りのしっかりしたトートバッグをもらいました！　まじ嬉しい！ 企業ブース イベントはトークセッションだけでなく企業ブースの参加もありました。CyberAgentさんによるKotlinPuzzlersが人気で、「ぱっと見では間違えてしまいそうなKotlinコード」がどのように動くのかを当てる内容です。 （ぱっと見でわからないコードってそもそも問題だよね） 僕も挑戦しましたがまんまと間違えたので早々に去りました。 Yahooさんのブースではくじ引き（外れました）とモブプロをやっていました。群衆（モブ）プログラミング（プロ）は皆に見せながらプログラミングすることで、外野と「これはこう書くよね」とコミュニケーションを取ることでコードの質を上げていくものです。 オープニング オープニングセッションでは主催の長澤太郎さん（以下太郎さん）によるKotlinの歴史やこれからのお話がありました。 Kotlinを愛でる が今回のテーマ。Kotlin in Actionの第二部のタイトルが元ネタだそうです。 Kotlinの歴史を振り返ると、発表から1.0まで5年ほど時間がかかりましたが、それからは怒涛の勢いでリリースされています。AndroidやSpring公式になることで利用ユーザーもどんどん増えていっています。 2011/7 kotlin発表 2016/2 1.0リリース 1.1コルーチン 1.2マルチプラットフォーム 2016/5 gradle 2017/4 native 2017/5 Android公式言語に 2017/9 Spring Framework5公式に 1.3コルーチンとインラインクラス 2013/7にはJapan Kotlin User Group（JKUG）も発足しており、勉強会、Slack、読本など精力的に活動しています。 サンフランシスコで開催されたKotlinConf 2017は1200人もの参加があり、世界中の開発者からのKotlinへの期待の高さが伺えます。 プレゼンでは以下のようにAndroidばかりではなく、サーバー用途でKotlinを使ってもらおうとしているようです。 Server 30% Android 24% Native 18% 次回のKotlinConf 2018は2018/10にアムステルダムで開催。 3days、61speakerになり、規模が一気に拡大しています。 （僕も行きたいと思ってたけどSold Outでした） Ktor game graphQL GCP など、Kotlinを色んな所で色んな使い方をする発表がたくさんあるようです（行きたかった）。 話は戻り、KotlinFestは多くの協賛企業に支えられており、積極的にKotlinを採用していっているようです。スポンサーは募集してから即日で埋まったみたいです。 企業名 導入内容 BIZREACH Server CA Android LINE Android, Server, Clova M3 Android, Server mercari Android mixi Android sansan Android YAHOO Android, Server dmm ほか 藤原さんからはKotlinの現状のまとめのお話でした。 Kotlinの特徴は以下の通り。 マルチプラットフォーム 型言語 関数型、オブジェクト指向 OSS そして、Kotlinには哲学があるとのこと。 実用主義 Javaの考え方のまま。学習が容易。 完結 読みやすい。ボイラープレートは少ない 安全 静的型付け、NULL安全、スマートキャスト 相互運用性 Javaと仲良し 現在の日本語本は代表的なところで以下があり、入門と中級をカバーしています。 Kotlin in Action 赤べこ、黒べこ みんなでKotlinを愛でましょう ということで、KotlinFestはスタートしました。 お昼ごはん オープニングセッションが終わったらいきなりランチタイムです。KontributorであるshirajiさんがTwitterで ぼっち飯を回避する ランチの相手を募集していたので、ご一緒させていただきました。 明日Kotlin Festでランチ誰か一緒に行かないですか？サーバサイドKotlinの話したい方、Kontributeしたい方、弊社興味ある方ぜひ！！！自分含めて四人くらいで！ （自腹でお願いします。。。） — shiraji （@shiraj_i） 2018年8月24日 美味しいお肉を皆で食べました。美味しかったです。 Kotlinで改善するAndroidアプリの品質 Android界の著名人であるあんざいゆきさんに拠るアプリ品質のお話です。 JavaのソースをKotlinに移行するとして、移行の難しさ、書き直しコスト、リグレッションなどの問題が出てくるけど、「Kotlin化にはそれを上回る効果あるのか？」を考える内容です。 まず、 品質 について、[オブジェクト指向入門~原則・コンセプト~]（ https://www.amazon.co.jp/dp/4798111112 ） に「品質とは何か」がまとめられているので、この発表ではこれを基準とされていました。 外的品質要因 ユーザーが認識 スピード、つかいやすさ 要因 正確さ 頑丈さ 拡張性 再利用性 内的品質要因 それ以外 モジュール性、読みやすさ JavaからKotlinにソースを書き直しても、アプリの使いやすさは変わりません。しかし、内的品質要因は外的品質要因に影響するので、アプリを使いやすくするときに内的品質を向上していると良い影響が出ると説明されています。 Javaの実装パターンをまとめた名著である Effective Java とKotlinの実装をいくつか説明していくことで、Kotlin化の正当性を説明されています。 builder pattern コンストラクタの引数を増やすのではなく、Builder Patternを使うようにするのがJavaでのテクニックでした。 ※このサンプルソースは僕が考えたものです。 コンストラクタの場合 第1引数と第2引数が同じStringのため、2つを間違えてしまう可能性があります。これがbuilder patternを使うと分かりやすくなります。 User user = new User（ "shikajiro" , "fukuoka-city" , Gender.MAN）; builder patternの場合。 User user = User.builder（） .name（ "shikajiro" ） .gender（Gender.MAN） .address（ "fukuoka-city" ） .build（）; nameと"shikajiro"が対になるので分かりやすいですね。 builder patternの欠点は、このための実装をUserクラスにする手間がかかることです。 Kotlinだとこのbuilder patternは名前付き引数でできます。 val user = User（name= "shikajiro" , gender=Gender.MAN, address= "fukuoka-city" ） ただし、Kotlinの名前付き引数は1つの引数に複数個指定とかできないので、場合によってはbuilderの方が良い時もあるとのことでした。 など、他に数パターン、Effective Javaに書いてある問題がKotlinでは解消される事の説明がありました。 これはつまり、Kotlin化を進めることでコードの内的品質が向上し、結果的にはユーザーの使いやすさに繋がるということです。 最後に 「明瞭で、正しく、再利用可能で、頑丈で、柔軟性があり、保守可能なプログラムが書ける」 と締めくくられていました。 How to Test Server-side Kotlin エムスリー株式会社の鈴木さん、前原さんのお二方に拠るテスト実装の実体験です。 Androidアプリはテスト実装の経験があるのですが、サーバーはあまり触ってなかったので聞かせていただきました。 基本的に標準である、JUnit4, Mockito, AssertJを選択したとのことです。テストライブラリはたくさん出てきているそうですが、まずは標準であることの信頼を選んだようです（変なところハマると辛いですもんね…）。 選択するライブラリが沢山あるので、開発チームに合うものを選定するのが大事になりそうです。 歴史的な経緯 によりDBが肥大化しているため、実装と切り離す必要があり、 いきなり全てをテストするのは困難なので、まずはアプリケーション層を主にテストしたそうです。 コンストラクタが肥大化したクラスのデータ作成が大変辛くなったので、IDEからテストコードを自動生成するものを作ったそうです。 Kotlinでもテストちゃんと書ける！ ということで、サーバー実装をする際は積極的に使っていきたいです。 Kotlin linter DMM釘宮さんによるLinter開発のお話です。 KotlinにはいくつかLinterがあるので、技術選定の材料にしてほしいので壇上に上がってくださったようです。 Linterは現在有名なものが3種類。 ktlint detekt android-lint ktlint linterをカスタマイズするには AST を知る必要がある。 ASTはツリー構造。PsiViewerを使う事でASTをビューできるので、これを使いながら進めると良いとのこと。 （なんとなくAPI responseのパーサーを実装したときを思い出しました） カスタムルールのformaterも作れるけど、実装する必要がある（lintルールとformatterが乖離するのはとても辛そう） detekt ktlintより高機能だが、フォーマット機能は途中からなくなったようです。カスタムルールでは作れるらしいです。 Kotlinコルーチンを理解しよう 株式会社Lang-8八木さんによるコルーチンの解説です。 コルーチンの歴史を紐解くと、1963年にメルヴィンコンウェイがcobolコンパイラでコルーチンの概念を出したそうです。 コルーチンとは 一時停止可能な計算インスタンス であり、スレッドに似ているけど、スレッドに束縛されないのが特徴です。継続状況を持つプログラムが容易に記述できます。Future Promiseみたいに値を返すことも可能です。 プレゼンでは、コルーチンがどのように実現しているかをKotlinから生成されたバイトコードを紐解いて探求していきます。 そこから、コルーチンはステートマシンで表現されていることがわかります。 詳しい説明はプレゼン資料を見ていただくとして、ここではサンプルソースを以下にまとめます。 var rootJob: Job = Job() val job = launch(UI, parent = rootJob) { repeat( 3 ) { try { //直列 val hoge = async {} async { hoge.await() }.await() //並列 async {}.await() async {}.await() return @launch } catch (e: CancellationException ) { } catch (e: Exception ) { if (souldRetry(e)) { return @repeat } } } } job.cancel() rootJob.cancel() 他にも以下のライブラリがコルーチンに対応しているので、Androidでも使わない理由はないようです。 Retrofit EventBus, Channel gistに転がっているらしい android-coroutines onActivityResultをsuspend How to Kontribute v4 JP ランチをご一緒したUBieの磯貝さんによる、KotlinプロジェクトへのContributeの仕方の解説です。 磯貝さんはOSSであるKotlinにコントリビュートした日本人として有名になりました。 photos.google.com KotlinはKotlinで書かれているため、Kotlinを愛している方にはもってこいです。Kotlin Pluginコントリビュータが多いので、決して難しいものばかりではないようです。 Kontribute手順は発表資料に委ねたいと思います。 僕自身、磯貝さんのブログに触発され、DroidKaigi2018のAndroidアプリへのContributeを決意しました。結構エグいIssueを辛うじてfixさせることができ、大きな自信へと繋がりました。 この記事を見ているみなさんも、もしContributeに興味がありましたら磯貝さんの記事をご一読ください！ クロージング Kotlin Fest 2019は現時点では未定とのことです。もしやるなら次回はBigゲストを招待したいとのことでした。 懇親会 さぁ、ついに本番が始まりました。懇親会にも多くの参加者、発表者の方が参加し、Kotlin愛を語り合っていました。 スタッフの皆さん、本当にお疲れ様でした。 こうして、しかじろうのKotlinFestは幕を下ろしました（この後Android老人会の皆さんと二次会に行きました）。 引用 Top画像は https://kotlin.connpass.com/event/91666/ より引用させていただきました さいごに スタートトゥデイテクノロジーズではKotlinを使ってアプリ・サーバーを開発するエンジニアをこれでもかというほど募集しております。 www.wantedly.com www.wantedly.com www.wantedly.com 福岡研究所でも機械学習などを使ってファッションを科学する研究者を募集しております。 www.wantedly.com

こんにちは、新事業創造部の遠藤です。現在WEARの開発を行っています。 最近はWEARのコーディネート一覧やユーザー一覧など、リスト画面にバナー型の広告を実装をしました。 リストにデータを挿入する実装は簡単なように思えますが、種類の違うデータを扱う場合には、考慮するべきポイントがいくつかあります。 本記事ではリストに広告を表示することを例に、種類の違うデータをリストに挿入する際のデータの持ち方・実装ついて紹介したいと思います。 仕様 リスト画面にバナー型の広告を表示するにあたっての仕様は以下のとおりです。 広告を取得できない場合はリストをつめる スクロールして戻っても同じ広告が表示されている 広告のインプレッションは表示時のみとなるように制御する スクロールに合わせて遅延なく広告の表示をする 上記のような元々表示していたデータと異なる仕様を扱うため、実装が複雑になります。 バナー型広告について リストにデータを挿入する実装を紹介する前に、表示しているバナー型広告について軽く触れたいと思います。 今回はGoogle Mobile Ads SDKが提供しているバナー型広告(DFP)をリストに表示しています。 このバナー型広告は広告取得リクエストをするとdelegateメソッドを通じて表示するバナーのオブジェクトが取得できます。 import GoogleMobileAds class ViewController : UICollectionViewController , GADBannerViewDelegate { let banner : DFPBannerView ! override func viewDidLoad () { super .viewDidLoad() // バナー広告のインスタンスを生成してリクエスト banner = DFPBannerView() banner.adUnitID = "xxxxxxxxxxxxxxxxx" banner.delegate = self banner.request(DFPRequest()) } func adViewDidReceiveAd (_ bannerView : GADBannerView ) { // 広告取得成功のdelegate } func adView (_ bannerView : GADBannerView , didFailToReceiveAdWithError error : GADRequestError ) { // 広告取得失敗のdelegate } } また、広告が表示されなくても広告取得が成功したタイミングでインプレッションの計測がされるようになっています。 インプレッションを手動でカウントする仕組みはあるのですが、第三者ネットワーク広告には使用できないです。 実装について データの持ち方について リストに種類の違うデータを挿入する際に肝となるのはデータの持ち方だと思います。 データ保持の方法はいろいろあると思いますが、今回は以下の考慮するポイントをもとにデータの持ち方について検討しました。 考慮するポイント 　 1. 広告が取得できない場合の対応 2. cellの再利用 3. インプレッション計測を正しく行う 1. 広告が取得できない場合の対応 広告を取得できなかった場合にリストをつめる簡単な方法は、cellの高さを0にすることだと思います。 しかし、UICollectionViewで minimumLineSpacing を使用して実装している場合は気をつけないといけません。 高さを0にすることでリストがつまったように見えますが、cell自体は残っています。 高さを0にしたcellの minimumLineSpacing と前のcellの minimumLineSpacing が合わさりコンテンツ間のスペースが広く見えてしまいます。 なので、広告が取得できなかった場合には高さを0にする方法ではなくデータでの制御が必要になります。 2. cellの再利用 UITableViewやUICollectionViewはcellが再利用されます。 cellを表示するタイミングで広告のリクエストを行うと、スクロールするたびに違う広告が表示されてしまいます。 この問題を解決するために、バナーのViewを保持する必要があります。 3. インプレッション計測を正しく行う スクロールに合わせて遅延なく広告を表示するために、広告の先読み処理を行うと思います。 しかし今回導入したバナー型広告は、広告を取得したタイミングでインプレッション計測が行われます。 たくさんの広告を先読みしてしまうと、広告を表示していないのに、インプレッション数が増えてしまいます。 なので、表示する直前に1件ずつ広告取得のリクエストを行う必要があります。 上記の考慮するポイントをから、以下の3種類のリストデータを持つことにしました。 リスト画面で表示するコンテンツのみのリストデータ コンテンツ、AD、ADを入れる位置を確保するためのスタブのリストデータ ADの位置を確保するためのデータです。 コンテンツと取得できた広告だけのリストデータ 表示に使用するためのデータです。 UICollectionViewのdataSource、delegateで使用します。 ADを入れるための位置を確保したデータと表示に使用するデータを分けることにしました。 これにより実際に取得できた広告のみデータとして扱われることになるので、広告の取得が失敗したときにcellの高さを0にするという対応をしなくてよくなります。 また、広告の表示位置をスタブを使用して確保するようにしました。 そうすることで広告を挿入するたびに、挿入する位置の計算をしなくてよくなります。 リストのデータについてですが、スクロールして戻っても同じ広告を表示する仕様を実現するために、表示するバナーのViewをデータとして保持することにしました。 実装 データの持ち方が決まったので、リストに種類の違うデータを挿入する実装について大まかに説明していきます。 今回はわかりやすいように、リストに3件ずつ広告を入れる仕様で説明したいと思います。 1. コンテンツのリストデータに広告のスタブを挿入する リスト画面に表示するコンテンツが取得できたら、広告のスタブを挿入していきます。 複数の型を扱うためにenumの配列で実装しています。 class ViewController : UICollectionViewController { enum CellType { case contents(Contents) case ad(DFPBannerView) case adStub } private let adInterval : Int = 3 // 3件ずつ広告を表示する private var contentsList : [Contents] = [] // コンテンツのみのリスト private var dataList : [CellType] = [] // ADスタブが入ったリスト // APIリクエスト完了後に行う処理 // contentsListにはAPIから取得できたデータが追加されている private func insertAdStub () { // データを3件ずつに分割する let chunks = stride(from : 0 , to : contentsList.count , by : adInterval ).map { contentsList[ $0 ..< Swift.min( $0 + adInterval, contentsList.count)].map { CellType.contents( $0 ) } } // 分割したデータにAdStubを挿入していく dataList = chunks.map { ( $0 .count == splitSize) ? $0 + [CellType.adStub] : $0 }.flatMap { $0 } } } 2. 広告の挿入 広告の取得リクエストを行い、実際に表示するバナーのViewが取得できたら、AdStubと置き換えていきます。 import GoogleMobileAds class ViewController : UICollectionViewController , GADBannerViewDelegate { private var ads : [DFPBannerView] = [] private var dataList : [CellType] = [] private var ad : DFPBannerView ? private var latestAdIndex : Int = 0 override func viewDidLoad () { super .viewDidLoad() requestAd() } fileprivate func requestAd () { let bannerView = DFPBannerView() bannerView.adUnitID = "" bannerView.rootViewController = self bannerView.delegate = self bannerView.load(DFPRequest()) ad = bannerView } private func insertAd (bannerView : DFPBannerView ) { for index in latestAdIndex ..< dataList.count { if case .adStub = dataSorce[index] { dataList[index] = .ad(adView) latestAdIndex = index return } } } // MARK: - GADBannerViewDelegate func adViewDidReceiveAd (_ bannerView : GADBannerView ) { guard let bannerView = bannerView as ? DFPBannerView else { return } ads.removeFirst() insertAd(adView : adView ) } } 3. 表示 実際に表示するデータはAdStubを抜いたデータを使用します。 import GoogleMobileAds class ViewController : UICollectionViewController , GADBannerViewDelegate { private func displayData () -> [CellType] { return dataList.filter { if case .adStub = $0 { return false } else { return true } } } // MARK: - UICollectionViewDataSource override func collectionView (_ collectionView : UICollectionView , numberOfItemsInSection section : Int ) -> Int { return displayData().count } override func collectionView (_ collectionView : UICollectionView , cellForItemAt indexPath : IndexPath ) -> UICollectionViewCell { if let contents = displayData()[indexPath : indexPath ] { ・・・ } else if case .ad = displayData()[indexPath.item] { ・・・ } else { fatalError( "Unexpected Display Data" ) } } } 4. 広告は1件ずつリクエストを行う インプレッション計測を正しく行うため、広告を表示する直前に広告取得のリクエストをするようにしました。 しかし表示する直前にリクエストを行うと、広告を表示したいタイミングに広告を取得できないことがあります。 広告が取得できていないと、スクロールして広告を表示する位置にきても広告を表示できません。 なので遅延なく広告を表示するために、直前に広告取得を行うのではなく、少し早いタイミングで広告の取得を行うようにしました。 今回は以下のタイミングで広告の取得リクエストを行っています。 初回表示（viewDidLoad） 広告が表示 広告の取得失敗 import GoogleMobileAds class ViewController : UICollectionViewController , GADBannerViewDelegate { override func viewDidLoad () { super .viewDidLoad() requestAd() } fileprivate func requestAd () { let bannerView = DFPBannerView() bannerView.adUnitID = "" bannerView.rootViewController = self bannerView.delegate = self bannerView.load(DFPRequest()) ad = bannerView } // MARK: - UICollectionViewDataSource override func collectionView (_ collectionView : UICollectionView , cellForItemAt indexPath : IndexPath ) -> UICollectionViewCell { if let contents = displayData()[indexPath : indexPath ] { ・・・ } else if case .ad = displayData()[indexPath.item] { requestAd() } else { fatalError( "Unexpected Display Data" ) } } // MARK: - GADBannerViewDelegate func adView (_ bannerView : GADBannerView , didFailToReceiveAdWithError error : GADRequestError ) { requestAd() } } 以上が今回バナー型広告をリストに挿入する実装についての説明です。 まとめ リスト画面に種類の違うデータを挿入する実装についての紹介でした。 広告など種類の違うデータをリスト画面に挿入して表示する際の参考になれば幸いです。 スタートトゥデイテクノロジーズではiOSエンジニアを募集しています。少しでも興味がある方は、ぜひ一度オフィスにお越しください。 下記からのエントリーもお待ちしています。 www.wantedly.com

こんにちは。スタートトゥデイ研究所の真木です。 8月5日から8月8日にかけて開催されたMIRU 2018という学会に行ってきました。また、5月下旬から約2か月間にわたって実施されてきた「MIRU若手プログラム」という 若手研究者同士 の交流プログラムにも参加してきたので、今回はその報告をします。 MIRUとは MIRUは正式名称を「画像の認識・理解シンポジウム」といい、21回目となる今年は札幌で開催されました。画像に関する研究の基礎から応用までがスコープに含まれ、この分野の学会としては 国内最大規模 です。今年は 700人 以上の参加があったようです。 通常のポスター発表とオーラル発表に加え、画像認識のトップカンファレンスであるCVPRで採択された論文の招待講演、4件のチュートリアル講演、海外のトップ研究者を招聘した特別講演、異分野の研究者が集って将来展望について議論する特別企画など盛りだくさんの内容でした。 どの発表も素晴らしかったのですが、特に高橋さん（オムロン）によるGANのチュートリアルは、数式による説明と図・動画による説明のバランスが絶妙で大変素晴らしく、勉強になりました。 チュートリアル講演の一部は以下で発表資料が公開されています。 画像認識分野における深層学習〜CNN, RNNからマルチタスク学習まで〜，山下隆義（中部大学） MIRU MIRUわかるGAN，高橋智洋（オムロン株式） スタートトゥデイと画像認識 スタートトゥデイ研究所では、ファッションに関わる基礎・応用研究を行なっており、研究の道具として画像認識をよく利用しています。例えば、商品の画像からカテゴリを自動的に認識したり、アイテム画像の組み合わせからオシャレに見えるコーディネートを推薦する研究などを行なっています。 そこで画像認識の知見をさらに深め、この分野の研究者と交流するため、スタートトゥデイ研究所はMIRU2018にゴールドスポンサーとして協賛し、企業ブースで研究を紹介しました。 大変うれしいことに、多くの方々が私たちの研究に興味を持ってくださいました。ポスターまで足を運んでくださった皆さま、ありがとうございました。 こちらは期間中展示していたポスターです。 若手プログラム MIRU若手プログラムは画像認識に興味を持つ若手研究者の交流企画で、学生を中心に大学の研究者、企業の研究者など40名以上の若手研究者が集まりました。企画内容は、「異分野サーベイ」や「若手の未来を議論する」などの真面目な企画だけでなく、自己紹介LTや写真の「インスタ映え」を競うエンタメ系の企画もあり、本会議と並んでこちらも盛りだくさんでした。 メインの企画である異分野サーベイでは、参加者が画像認識以外の7つの分野から1つを選び、その分野のサーベイを行います。これは、異分野で使われている手法から着想を得て画像認識に持ち込んだり、逆に画像認識で使われている手法をその他の分野に持ち込むことでブレークスルーを起こすことを意図したものです。サーベイ分野は（1）ロボティクス（2）自然言語処理（3）HCI（4）心理学（5）データマイニング（6）音声（7）生体の7つで、わたしはデータマイニングのグループに参加しました。 各グループには若手P実行員が1人ずつオブザーバとして参加し、議論をファシリテートしてくれました。 サーベイを始めるに際し、まず5月中旬に実行委員の米谷さん（東大）と片岡さん（産総研）からそれぞれサーベイ論文の書き方やグループサーベイの方法について以下の資料が提供されました。これを読むだけでもかなり勉強になるのでおすすめです。特に、サーベイは単に新しい論文をまとめるのではなく、分野に対する 新しい視点 を読者に与えることが重要であるという米谷さんの指摘には蒙を啓かれました。 サーベイ論文の書き方，米谷竜（東京大学） https://www.dropbox.com/s/vvqxs698en01uf2/PRMU180518_yonetani_small.pdf グループサーベイ方，片岡裕雄（産業総合研究所） http://hirokatsukataoka.net/temp/presen/180518PRMU_Kataoka.pdf これを受け、各グループの参加者たちはそれぞれ遠隔地にいながらもSlack、Git、Skypeなどのツールを駆使して、約2か月半に渡ってサーベイに取り組んできました。わたしにとっては、自分の研究分野以外の分野をサーベイすること、チームで協力しながらサーベイをすること、その両方が初めての体験でした。研究者として成長していく上で、とても貴重な機会だったと思います。 サーベイの成果はMIRU期間中にポスターでMIRU来場者に向けて発表し、さらに本会議翌日に口頭発表を行いました。他のグループの発表を聞くことで多様な分野の最新動向を把握することができ、とても勉強になりました。全チームの発表資料が下記のURLにて公開されているので、ぜひご覧ください。 MIRU若手プログラム 異分野サーベイ 発表資料 https://sites.google.com/view/miru2018sapporo/wakate_top/各チームの発表資料 若手プログラム通じてたくさんの学生や他企業の方々と仲を深めることができ、またデータマイニングに関する知見を深めることができ、非常に有意義でした。若手P参加者のみなさん、実行委員の皆さん、本当にありがとうございました！ 最後に スタートトゥデイ研究所はまだできたばかりですが、ファッションという未開拓な分野を科学的な方法論で探求し、その成果を社会に還元するべく日々研究を行なっています。研究成果は、原則として会社内に留めることなく論文として公開していきます。 私たちと一緒にファッションの研究に挑戦しませんか？スタートトゥデイ研究所では豊富なデータ資産と潤沢な予算のもと研究を行うことができ、国内・国外を問わず業務として学会に参加できます。もちろん、論文を書くだけでなく研究成果を実際のサービスへ実装することでたくさんのユーザーに貢献することもできます。また、MIRU若手Pのような機会への参加を応援してくれる自由な社風があります。 ご興味のある方は、以下のリンクからぜひご応募ください！ www.wantedly.com また、私たちの持つデータ資産を活用した共同研究の募集も行なっております。画像認識・機械学習はもちろん、社会科学や認知科学などファッションに関わる幅広い分野で研究を行いたいと考えていますので、ご興味のある方はぜひ以下のリンクからご連絡ください！ https://www.starttoday-tech.com/contact/ www.starttoday-tech.com

こんにちは。新事業創造部インフラチームの内山（@k4ri474）です。 弊社が運営する IQON というサービスでは、長らくMySQLのバージョン5.6.27を利用していました。これは2018年9月にEOLを迎えるため、RDSの方針として強制アップグレードがアナウンスされています。 MySQLを継続する選択肢もありましたが、Auroraの運用知見が溜まっていたということもあり、これをキッカケにMySQLからのAurora移行を実施しました。 新事業創造部ではほぼ全てのAWSリソースをCloudFormationを使って宣言しているため、例に漏れずAuroraもテンプレートへ落とし込むことにしました。 ただ、CloudFormationだけで完結しない作業があったので、今回はCloudFormationでの宣言とコンソールからの手作業を織り交ぜるという対応を取っています。 執筆時点の公式ドキュメントではカバーできていない需要を満たすべく、 CloudFormationを使ったAmazon Auroraへの移行 の手順を皆さんに共有したいと思います。 利用したサービス AWS CloudFormation AWS CloudFormation はAWSのほぼ全てのリソースをテキストベースで管理し構築できるサービスです。 1 構築にはYAMLもしくはJSON形式で記述された テンプレート というテキストファイルを利用します。設計のタイミングで、どのリソースをどういったプロパティで作成するかをコントロールできます。 CloudFormationのテンプレートを使い回すことで、数クリックでサービス環境一式を複製できます。 また、ネットワークの詳細をテキストで表現するため、設計のノウハウをチーム内で共有できたり、他チームに提供する資料としてそのまま使えるというメリットもありますね。 Amazon Aurora Amazon Aurora はAWSの Amazon RDS というサービスで利用できる、MySQL・PostgreSQLと互換性のあるリレーショナルデータベースです。 特徴を何点か抜粋してみました。 パッチの自動適用 最大16TBまでオートスケールされるストレージ リードレプリカによる読み取りスループットの容易なスケール 読み込みエンドポイントによるリードレプリカの抽象化 僕のおすすめポイントは、読み込みエンドポイントがRDS版のロードバランサ感覚で使え、裏側のインスタンスの台数をクライアント側で管理する必要がなくなったことです。 2 Auroraへの移行 Auroraへの移行は、大雑把に言うとMySQLをAuroraで複製し、アプリケーションの接続DBをAuroraへ変更することで実現できます。 複製を作る過程でAuroraクラスタの呼称が変わるのでここで補足しておきます。 MySQLから非同期的にデータをコピー（レプリケーション）してきている段階のAuroraクラスタをAuroraリードレプリカといい、レプリケーションを止めて独立した状態のAuroraクラスタをスタンドアロンAuroraクラスタと呼びます。 今回はスタンドアロンAuroraクラスタをどうやってCloudFormationで作成するかにフォーカスして説明を行います。 AWS公式ドキュメント で示されている手法で移行を行うと、以下のような手順になります。 可能な限りCloudFormationで宣言したい部署の方針に沿って、この手順をテンプレートで最大限表現しようと思います。 CloudFormationでは次の作業ができることを期待し、検証を開始しました。 Auroraリードレプリカの作成とスタンドアロンAuroraクラスタへの昇格がCloudFormationのテンプレートで表現できれば、手作業を介さずに移行できます。 ただ、現実はこうでした。 結論として、リードレプリカの昇格はCloudFormationで実装できませんでした。 CloudFormationでは、Auroraクラスタ作成において Auroraリードレプリカの作成 か クラスタのスナップショットからクラスタを復元 することしかできません。 そのため、Auroraリードレプリカを昇格する作業は手作業となってしまいます。 ただ、普通に手作業で実施すると テンプレートの記述と実際のリソースに相違が発生 してしまいます。 これを解消するため、以下の手順で移行を実施しました。 Auroraリードレプリカの作成をテンプレートで宣言 コンソールにてAuroraリードレプリカを昇格 コンソールにてスタンドアロンAuroraクラスタのスナップショットを取得 手順1のテンプレートを再利用して手順3のスナップショットから新しいスタンドアロンAuroraクラスタを作成 この手順を踏むと、テンプレートの記述と実際のリソースが一致します。 実際に移行を行うにあたって、まずはスケジュールを説明します。 スケジュール 今回の作業ではメンテナンス前に実施する作業と、メンテナンス中に実施する作業が存在します。 メンテナンス前：Auroraリードレプリカの作成（手順1） メンテナンス中：Auroraリードレプリカの昇格以降、全ての手順（手順2・3・4） Auroraリードレプリカの昇格を実施するとレプリケーションが切れ、MySQL Masterとの差分が発生します。そのため、トランザクションが無くなってから手順2以降を実施する必要があります。 それでは、本題の各手順の内容を説明していきます。 1. Auroraリードレプリカの作成 RDS for MySQLからの移行に当たって、まずはMySQLからレプリケーションを受けるAuroraリードレプリカを作成する必要があります。 この作業はCloudFormationで宣言することが可能で、テンプレートで表すと以下のようになります。 # Auroraクラスタを作成 MyRDSDBCluster : Type : "AWS::RDS::DBCluster" Properties : # （各種必須プロパティを省略） Engine : 'aurora' EngineVersion : '5.6.10a' ReplicationSourceIdentifier : 'arn:aws:rds:<AZ>:<AccountId>:db:<SourceInstanceName>' # Auroraインスタンス1台目を作成 MyRDSDBInstanceApplicationFirst : Type : "AWS::RDS::DBInstance" Properties : # （各種必須プロパティを省略） DBClusterIdentifier : !Ref MyRDSDBCluster Engine : 'aurora' # Auroraインスタンス2台目を作成 MyRDSDBInstanceApplicationSecond : Type : "AWS::RDS::DBInstance" Properties : # （各種必須プロパティを省略） DBClusterIdentifier : !Ref MyRDSDBCluster Engine : 'aurora' ポイントは以下の2点です。 クラスタ側でReplicationSourceIdentifierというプロパティを記述し、レプリケーション元となるMySQLインスタンスのARNを指定する インスタンス側ではDBClusterIdentifierというプロパティを記述し、所属するクラスタを指定する これでMySQL Masterからレプリケーションを受けているAuroraクラスタができます。 2. Auroraリードレプリカの昇格 次に実施するのはAuroraリードレプリカをスタンドアロンのAuroraクラスタに昇格させる作業です。 この手順をなんとかCloudFormationで実装しようとしてテンプレートをぽちぽち弄ってみたのですが、実現出来ませんでした。 3 よって昇格は Aurora リードレプリカの昇格（AWS マネジメントコンソール） に記載された手順で実施しました。 先述の通り、この時点でテンプレートではAuroraリードレプリカ、実際はスタンドアロンAuroraクラスタが構築されており、差異があります。 これを解消するため、3・4の手順を踏んでテンプレートを実態に即したものへ修正します。 3. スナップショットの取得 最終的な スナップショットからの復元 の前準備として必要なのがこの手順3です。 この作業もテンプレートでは表現できないため、 DB スナップショットの作成（AWS マネジメントコンソール） に記述された手順で実施しました。 4. スナップショットからのクラスタ復元 最後に、テンプレートを使って手順3で取得したスナップショットからAuroraクラスタとAuroraインスタンスを復元します。 この手順は、手順1で作成したテンプレートを1行変更するだけで実現できます。 テンプレートに加える修正を以下にdiffで示します。 < ReplicationSourceIdentifier: 'arn:aws:rds:<AZ>:<AccountId>:db:<SourceInstanceName>' --- > # ReplicationSourceIdentifier: 'arn:aws:rds:<AZ>:<AccountId>:db:<SourceInstanceName>' > SnapshotIdentifier: arn:aws:rds:<AZ>:<AccountId>:cluster-snapshot:<SnapShotName> ReplicationSourceIdentifierの代わりにSnapshotIdentifierが有効になり、スナップショットを元にクラスタを作成するという宣言に代わります。 このテンプレートを反映すると、レプリカとして宣言していたAuroraクラスタとインスタンスが削除され、スナップショットから復元されるクラスタ・インスタンスで置換されます。 古いクラスタ・インスタンスを削除する手間が省けました。 DBClusterIdentifierで指定したAuroraクラスタが別のものになることで、インスタンスも再構築されています。 以上でCloudFormationを使って、 MySQLのAuroraレプリカが昇格したスタンドアロンAuroraクラスタ を構築できました。 後はアプリケーションの接続DBをこのスタンドアロンAuroraクラスタへ変更することで、無事移行が完了となりますね。 まとめ 今回の4つの手順を経て作成されたテンプレートは、サービスインした実際のAWSリソースを正しく表現したものとなりました。 メンテナンス中にAuroraクラスタを置換する必要があり、しかも手作業も発生するという困った状況でしたが、今回の方針で進める大きな決め手となったのは 事前に検証とリハーサルを繰り返して作業時間を正確に見積もれた ことです。本番での不確定要素を最小限に出来たことで踏み切れました。 テンプレートで表現できたため、今後はメンテナンスウィンドウやセキュリティグループなどの変更をコードベースでレビューを挟んで実施できますね。 さいごに スタートトゥデイテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ https://www.starttoday-tech.com/recruit/ サービスに追加された新機能がCloudFormationで実装されるまでにはそれなりにラグがありますが、そことはうまく付き合っていきます。 ↩ コネクションを受けているリードレプリカをクラスターからいきなり抜くとRDSはよしなに再接続処理をやってくれるんだろうか？という疑問はあります。スケールアウトは気軽にできますが・・ ↩ AuroraクラスタのReplicationSourceIdentifierを外してレプリケーション設定を削除することが有効だと思ったのですが、クラスタが削除されて新規にまっさらなクラスタが作成されるだけでした。 ↩

こんにちは！ スタートトゥデイテクノロジーズ新事業創造部の塩崎です。 2018年7月24日〜26日にかけてサンフランシスコでGoogle Cloud Next '18が開催されました。 このイベントに新事業創造部の塩崎、今村、そして代表取締役CIOの金山の3名で参加してきました。 この記事では多数あった講演の中で特に印象に残ったものをいくつか紹介いたします。 講演 Building A Petabyte Scale Warehouse in BigQuery How to Do Predictive Analytics in BigQuery A Modern Data Pipeline in Action Real-Time Stream Analytics with Google Cloud Dataflow: Common Use Cases and Patterns Securing Access to GCP resources Better Practices for Cloud IAM 感想 まとめ 講演 Building A Petabyte Scale Warehouse in BigQuery DataWareHouse(DWH)のBigQuery移行をするために行ったことを各社さんが発表するセッションでした。 特にSpotifyさんの発表では移行のための具体的なtipsを4つ紹介されていました。 その4つの内訳は以下のものとのことです。 Administration オンデマンド料金ではなく、定額料金を使う ビジネス的に重要なジョブ用にスロットを予約する Education ジョブのパフォーマンス監視のために、ジョブの並列度を監視 Dremelのアーキテクチャ、特に伝統的なRDBとの違い列指向であることの理解 Integration BigQueryのAPIを使用し、自社ツールを開発 GCPサービス間でのデータ移動が簡単なので、他のGCPサービスと統合 Partnership BigQueryのサポートチームに機能のリクエストを出す また、Oathさんは各部署で独立してDWHを持っている（データサイロ）ために、部署横断的なデータ活用が難しいという課題があったそうです。 BigQuery移行のために、当時使用されていたHiveのデータをBigQueryにコピーし、BIツールであるLookerに繋ぎこむことから始めたそうです。 現在ではGCP製品をフル活用したデータ分析基盤になっているそうです。 TwitterさんはMySQL、Vertica、HDFS等に保存されたデータをBigQueryにコピーする際、一旦Apache Avro形式に変換をしているそうでした。 Avroに変換してからBigQueryにインポートすることによって高速化されるようです。 海外のBigQuery導入事例を聞くとデータ量が本当に桁違いで驚愕することが多かったです。 発表のタイトルにもあるPB（ペタバイト）という単語が発表中に頻繁に飛び交っていました。 BigQueryは大量のデータに対してもスケールするという宣伝文句はよく目にしますが、具体的な数値を見るとBigQueryにDWHを構築する時の安心感が増します。 How to Do Predictive Analytics in BigQuery BigQueryの新機能であるBigQuery MLに関する発表でした。 BigQueryに格納されているデータに対して機械学習でモデルを構築できるそうです。 データ分析を行う人にとっていつも使い慣れているSQLに似た構文で機械学習を行うことができるようになります。 お手軽に試してみたい人向けの機能としては、ハイパーパラメーターの自動決定やデータを学習用とテスト用に自動的に分けてくれる機能があるそうです。 また、アドバンストな機能として、学習率の設定やデータを学習用とテスト用に分ける時の方法の設定を自分で変更できる機能もあるそうです。 現在は線形回帰と二項ロジスティック回帰のモデルがサポートされているそうですが、使用できるモデルはこれから拡充されるようです。 対象としているユーザー層はAutoMLやCloudML APIを使う層とTensorFlowやCloudML Engineを使う層の中間層らしいです。 発表の後半ではHearst Newspapersさんでの導入事例の紹介がありました。 オンラインで提供している新聞購読サービスの解約予測モデルの構築をBigQuery MLを使って行ったそうです。 利用ログやデモグラ情報などから、そのユーザーが解約するかどうかを二項ロジスティック回帰で予測するモデルだそうです。 このモデルを構築することによって、どの属性がユーザーの解約に寄与するのかを可視化することが出来たそうです。 プロトタイプの構築はわずか1日で行うことができ、本番投入もわずか2スプリントで行うことができたそうです。 BigQueryにすべてのログやマスタデータが集約されている環境では非常にパワフルな機能であると感じました。 大量のデータに対する機械学習をシンプルなSQL記法で行うことができるため、アナリストが自分で予測モデルをつくることの敷居が下がるかと思います。 まだモデルの種類は2種類しかありませんが、将来的に増えていくことを強く期待しています。 A Modern Data Pipeline in Action モダンなデータパイプラインを構築するためのパターンの紹介でした。 なお、データパイプラインとはデータに対して以下の一連の処理を行うためのシステムのことです。 Ingest → Transform → Store → Analyze → Visualize 発表中では以下のパターンが紹介されていました。 一度取得したデータに対して、再度処理をかける時のパターン プログラムのバグやビジネスロジックの変更に備えるためのパターンです。 PubSubからのデータをDataFlowでBigQueryに入れるための流れとは別に、GCSにAvro形式でデータを保存する流れを作ります。 もしもの時にはこのデータをDataFlowで再度処理してBigQueryに入れ直すことができます。 データのバックフィルをする時のパターン CloudComposer(マネージドAirflow)を使い過去分のデータをBigQueryに入れるのがベストプラクティスらしいです。 また、データパイプラインのアーキテクチャを考える上で重要なことも紹介されていました。 Decoupling DBやログストリームなどのデータを生成する部分をデータを消費する部分をPubSubを使って分離させる。 Simple, Elastic, low-cost マネージドサービスの活用によって、スケーリングとロードバランスに関する問題を考えなくても良いようにする。 Low Latency ETL処理の負荷を可能な限り小さくして、低レイテンシでBigQueryにデータを入れる。 Stream and Batch DataFlowを使うとストリーム処理、バッチ処理の両方を同一のソースコードで処理可能になる。 Easy re-processing DataFlowによる変換処理前のデータをGCSに保存することによって、容易に再処理をできるようにする。 High-Level DataFlowならば簡単な記述で大きな処理を行わせることができる。 Portability DataFlowはApache Beamでプログラミングできるため、ロックインされない。 バッチ処理とストリーム処理を同じソースコードで実現できることにDataFlowの実力を感じました。 現在DigdagとEmbulkを活用してETLを構築していますが、CloudComposerやDataFlowを使用したパターンとの比較も真面目に検討する必要性を感じました。 Real-Time Stream Analytics with Google Cloud Dataflow: Common Use Cases and Patterns ストリーミングデータをリアルタイム分析をするためのパターンの紹介でした。 ストリーミングデータの特徴として、途切れることがないこと、予期せぬディレイが発生することなどが紹介されていました。 また、そのためにWindowingやWaterMarkなどのバッチでデータを処理するときには考えなくてもよい概念も紹介されていました。 後半ではCloudDataFlowを使った時の頻出パターンの紹介がなされていました。 Exactly-onceの実現 PubSubはAtLeastOnceの取り出ししかサポートしないために、DataFlow側でExactly-onceを実現するための方法です。 各々のイベントのAttributeにイベントID（乱数）を埋め込み、Dataflow側でwithIdAttributeすることによってExactly-onceが実現されます。 壊れたデータの扱い PubSubにはリトライ機能があるため、壊れたデータがやってくるとそのデータを無限に処理しようとしてしまいます。 そのため、予期せぬ例外をtry-catchで拾い、それをdead letter用のTopicにpublishすることでこの問題に対処できるそうです。 また、壊れたデータを後から解析するためBigQueryに永続化をしたり、アラートを上げるためのTopicにpublishするなどの派生パターンもあるそうです。 スキーマ変更への対応 イベントにフィールドが追加された時に対処するためのパターンです。 BigQueryのテーブルに対するスキーマ変更はダウンタイムなしで実行できるため、フィールド追加を検知した時にテーブルの列追加を行います。 また、前述したリトライ機能によって、テーブルへの挿入に失敗したイベントの取得もできます。 リアルタイムにデータの非正規化をする BigTableにもデータを入れ、DataFlow上でそのデータとJOINすることによってリアルタイムでデータの非正規化を行います。 @SetupでBigTableへのコネクションを確立し、@Teardownでコネクションを閉じるようにすると良いそうです。 ストリーミングデータを処理するにあたって、データの到着が遅延するという特性はバッチ処理にはない概念です。 ですが、DataFlowを活用することによって、これらの問題に対処できる可能性も同時に感じました。 Securing Access to GCP resources VPCの新機能であるVPC Service Controlについての発表でした。 VPCの中にセキュリティ境界を作ることができ、そこに出入りする通信のルールを定めることができるそうです。 GCSバケットに対するアクセスを接続元IPによって制限し、専用線で接続されたオンプレ環境のみからのアクセスに限定するという使用例が紹介されていました。 オペミスによってIAMの設定をミスしてしまった時や、内部の人が悪意を持ってアクセス権を変えてしまった時の防波堤として機能するようです。 たとえIAMでアクセスが許可されていてもVPC Service Controlの設定が優先されるそうです。 この機能はまだアルファ版なので使うためには申請が必要ですが、早くも利用してみたい気持ちが高まります。 データ流出事件のレポートを読んでいると、その原因の多くがアクセス権設定のオペミスであることに驚かされます。 人間は誰しもオペミスをするので、このような仕組みで2重3重に防御することでデータ流出の危険性を低減できるのではと期待できます。 Better Practices for Cloud IAM Cloud IAMの説明とベストプラクティスの紹介でした。 発表の前半では、Cloud IAMの説明として、以下のようなことが紹介されていました。 プロジェクトは信頼境界を引くためのもの Resourceは階層構造を持っており上位階層の設定は下位階層に引き継がれる 後半では、具体的なベストプラクティスの紹介がされていました。 主に以下のようなことが紹介されていました。 ロールを割り振る対象はユーザーではなく、グループにする Google Groupで作成したグループに対して権限を割り振ることで新しい人が入った時の運用負荷が下がる。 可能な限り小さな権限を与える Primitive Roleはプロジェクト全体に対する権限を与えてしまうので、Predefined RoleかCustom Roleかを使うようにする。 追跡するための情報を残す 監査ログをGCSかBigQueryに保存する。 組織の構造をCloudIAMの階層構造に反映させる 組織全体の設定はOrganization Policyで管理し部署ごとの設定はFolderで管理する。 そして、サービス毎、環境（production、development、test）毎にプロジェクトを分ける。 プロジェクトは信頼境界を引くためのものということが目から鱗な発表でした。 今までは開発用のリソースと本番用のリソースを同一プロジェクトに入れていたため、アクセス権の設定に頭を悩ませることが多かったです。 あの時にプロジェクトを分けるという発想に至っていれば…という後悔も同時に感じました。 「とりあえず使って見よう！」という状態では後回しにされがちなIAMの設定を体系的に知ることができ、今後のGCP運用のための大きな知見でした。 感想 Google Cloud Next'18に参加することによって今まで知らなかったGCPの機能を知ることができました。 今まではAWSをメインのクラウドとして使用し、GCPはBigQueryを使うのみであったため、GCP全体を本格的に学習することはありませんでした。 しかし、いざGCPについて学習するとどのサービスもとても奥深く、自分の理解不足を強く実感しました。 また、今回はセッションを聞くことを中心に時間を過ごしましたが、Googleの人と直接話すことができる場にもっとを顔を出せばよかったと感じました。 そして、英語でのコミュニケーション力不足も強く痛感しました。 発表の最中に上手く聞き取れなかった部分を後で字幕付き動画で確認するととても平易な英語なことが分かり、落ち込むことが多かったです。 これからの弊社の大きな目標に海外展開がありますので、英語の継続的な勉強の必要性を実感しました。 まとめ 今回のGoogle Cloud Next'18は会社の出張という形で参加しました。 参加期間はすべて業務扱いとなり、交通費、宿泊費の他、出張手当も会社からサポートされました。 国外のカンファレンスへの参加のサポートはエンジニアとして非常にありがたいことであると感じました。 今回の出張で得た知見を日頃のサービス開発に生かしていきたいと思います。 スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ https://www.wantedly.com/companies/starttoday-tech/projects

こんにちは。新事業創造部の荒井です。 今回はiOSアプリの多言語対応について紹介します。 はじめに 私は今までいくつかのiOSアプリを運営してきましたが、どのアプリも日本語のみのサポートでした。現在関わっているWEARでは、すでに多言語対応が進められており、良い機会ですので個人的に知見がなかった多言語対応について調査をしました。今回は基本となる文字列の翻訳について触れていきたいと思います。 多言語対応 幅広いユーザーにサービスを使用してもらうには、言語と地域が非常に重要になってきます。日付、通貨、長さの単位など、言語、地域、文化によって異なることが多く、アプリケーションを世界的に出すには地域や文化に対応していく必要があります。現在WEARでは4つの言語対応を進めており、設定言語に応じて、アプリケーションをその言語に翻訳しています。対応している言語は以下の通りです。 日本語 簡体字中国語 繁体字中国語 英語 多言語対応をすることで、日本人以外の方にも使用していただく機会が増え、ユーザー増加が見込めます。 Localizationの手順 それでは設定言語によってアプリケーション内の文字列を複数の言語に変更する方法を紹介します。大まかに以下の流れになります。 PROJECTのLocalizationsに言語の追加をする Localizable.stringsを用意する NSLocalizedStringを使用し言語の切り替えをする 1. Localizationに追加 ローカライズの設定は PROJECT -> Info -> Localizations で行います。 はじめにBase Internatioalizationを有効にします。 Base Internationalizationを有効にする PROJECT -> Info -> Use Base Internationalization にチェックを付けます。これによりアプリケーションで使う文字列を.storyboardと.xibから分離します。こちらはXcode 5以降ではデフォルトで有効になっています。それ以前のバージョンから作成されているプロジェクトは公式の「 Base Internationalizationを有効にする 」が参考になるかと思います。 言語を追加する 次に PROJECT -> Info -> Localizations の「 + 」を押して言語を追加します。例では英語をBaseにしているので日本語を追加しています。 追加する言語を選ぶと、対応するファイルと File Types を選択する画面が表示されます。表示する文字列のみを対応する場合は Localizable Strings を選択してください。 2. Localizable.stringsの作成 翻訳したい文字列を定義しておくLocalizable.stringsを作成します。 メニューの Fille -> New -> File から Strings File を選択します。 作成したLocalizable.Stringsを選択し「 Localize... 」から言語を選択すると選択した言語がローカライズされます。 Base にチェックをつけることで Localizable.strings（Japanese） と Localizable.strings（Base） が作成されます。 作成したLocalizable.stringsを編集していきます。 ここではアプリケーションでよく使う文字列をサンプルとして定義しました。 Localizable.strings（Japanese） "Yes" = "はい" ; "No" = "いいえ" ; "Cancel" = "キャンセル" ; "Confirm" = "確認" ; "Search" = "検索" ; "Else" = "その他" ; "Edit" = "編集" ; "Done" = "完了" ; "Friend" = "友達" ; "Save" = "保存" ; "Title" = "タイトル" ; "Decide" = "決定" ; Localizable.strings（Base） "Yes" = "Yes" ; "No" = "No" ; "Cancel" = "Cancel" ; "Confirm" = "Confirm" ; "Search" = "Search" ; "Else" = "Other" ; "Edit" = "Edit" ; "Done" = "Done" ; "Friend" = "Friends" ; "Save" = "Save" ; "Title" = "Title" ; "Decide" = "Enter" ; 3. NSLocalizedString ここまでで準備は完了です。NSLocalizedStringを使用し言語の切り替えを実装します。 override func viewDidLoad () { super .viewDidLoad() let yes = NSLocalizedString( "Yes" , comment : "" ) let no = NSLocalizedString( "No" , comment : "" ) let cancel = NSLocalizedString( "Cancel" , comment : "" ) let confirm = NSLocalizedString( "Confirm" , comment : "" ) let search = NSLocalizedString( "Search" , comment : "" ) print(yes) print(no) print(cancel) print(confirm) print(search) } このコードを実行すると以下のように出力されます。 Yes No Cancel Confirm Search 言語を日本語に切り替えることによって文字列が日本語になるか確認します。 Edit Scheme の Application Language を変更すると簡単に確認ができます。 実行結果は以下のようになります。 はい いいえ キャンセル 確認 検索 Application LanguageでJapanese選択すると日本語に切り替わることが確認できました。 このようにアプリケーションで必要な文字列を定義して使用していきます。 翻訳のフロー 多言語対応されたアプリケーションを運用するには普段と違った工程が必要となります。 1つの言語のみサポートするサービスとの大きな違いは機能追加ごとに翻訳のプロセスが入ることです。 翻訳サービスを使用したり、社内に翻訳を担当するチームがあったりと様々だと思いますが、 現在のWEARはチーム内で完結しています。 開発段階で翻訳が必要なリストを作成し、各言語を母国語とするメンバーが翻訳を担当しています。 Localizable.stringsをエンジニアが管理する方法もありますが、Apple社が案内している翻訳の手順にXLIFF（XML Localization Interchange File FormatXLIFF）を使用した運用があります。 画像出展： インターナショナライゼーションとローカリゼーションのガイド XcodeからXLIFFファイルにエクスポートし、翻訳者がXLIFFを編集し翻訳完了後にXLIFFファイルをインポートをします。Androidなど複数プラットフォームで多言語対応を進める際に有用です。 まとめ 今回はiOSアプリの多言語化について紹介しました。今回は文字列だけでしたが、実際には日付・価格などの表示やレイアウト対応など考慮するべきことは多々あります。より多くのユーザーにサービスを使って頂けるよう日々改善を続けています。少しでも興味がある方は、ぜひ一度オフィスにお越しください。 下記からのエントリーもお待ちしています。 www.wantedly.com 参考文献 https://developer.apple.com/jp/internationalization/

（Icon Credit *1 ） こんにちは。スタートトゥデイ研究所の後藤です。 今回は、集合を入力として扱うネットワークモデルの紹介をしたいと思います。機械学習の多くのモデルは、固定長の入出力や順序のある可変長の入出力を扱うように設計されます。画像データやテーブルデータは各サンプルの入出力の次元を合わせて学習しますし、自然言語処理のコーパスや時系列データは入出力の順序を保持して利用します。 その一方で、可変長で順序のない集合データを扱うモデルの研究は最近になって取り組み始められたばかりです。我々が研究しているファッションの領域において、入力データを集合として扱いたくなる状況がたびたびあるため、理解を深めておきたい問題設定です。 コーディネートをアイテムの集合とみなす コーディネートに使われたアイテムの例 コーディネートをアイテムの組み合わせとして捉えた場合、1つのコーディネートはアイテムを要素とする集合であると見なすことができそうです。ここでは、1つのコーディネート内に同じアイテムは1度しか登場しないことと、アイテムには順序がないことを前提としています。後ほど触れますが、アイテムのカテゴリによる順序を設定して系列データとして扱う研究もあります（Han et al. 2017, Nakamura & Goto 2018）。 コーディネートデータを扱う過去の取り組み コーディネートデータの学習をするための過去の取り組みを紹介します。 Siamese Networks 集合データから2つのアイテムを取り出して固定長の入力として扱う例です。Veit et al. 2015では、ファッションスタイルの違いを反映した空間を学習する試みで、この手法を取っています。集合全体を評価することは一旦諦めて、入力を固定長にしてしまうことで、従来の枠組みを用いてモデルを構築できます。 (Veit et al. 2015, Figure 2) このタスクでは、ペアが集合全体の性質を持っている場合は良いですが、集合全体として初めて成り立つ性質を持っているようなタスクには使えません。1つ1つのアイテムからはスタイルは見えてこないが、トータルコーディネートを見て初めてスタイルが明らかになるような例を学習することは難しそうです。 Bidirectional LSTM コーディネートに使われるアイテムの数は可変長なので、系列データとみなして扱った例です。Han et al. 2017では、アイテムのカテゴリにより入力の順序を決め、コーディネートを系列データとしてBidirectional LSTMを学習しています。 (Han et al. 2017, Figure 2) この手法ではカテゴリによる入力の順序を定義しているため、同じコーディネートの評価をする場合でも入力するデータの順序を変えると、出力が変わると言う性質があります。論文中では、インプットするカテゴリの順番を入れ替えて学習すると、得られるモデルのクオリティ自体が変わることも指摘されています。入力する順序によって組み合わせの評価値が変わる性質は、タスクによっては不都合なこともあります。 集合データを直接扱う方法 Zaheer et al. 2017では集合データをストレートに扱う方法を提案しています。この論文では、集合を入力とする際に満たされるべき性質を持った、必要十分なネットワーク構造を示しています。ここでは、permutation invariantとpermutation equivariantについて紹介します。実装に関しては、著者自身のコードがgithubにあるため理解の助けになるかと思います。 github.com Permutation invariant Invariant modelのアーキテクチャ (Zaheer et al. 2017, Figure 5) permutation invariantのモデルを模式的に表したのが上図です。 集合データを入力とし、スカラーを出力する問題です。集合に対して1つの値を返すため、入力データの順序を変えても出力が同じになります。この性質をpermutation invariantと呼びます。例えば、コーディネートに点数をつける、といったタスクが当てはまると考えられます。 関数 がpermutation invariantであるとは、任意の並べ替え に対して、 が成り立つことです。 論文では、集合の各要素の特徴を関数\( \phi(x)\)により独立に抽出し、それを足し上げたものを非線形関数\( \rho\)に渡すことで、permutation invariantな関数が実現できることを証明しています。各要素の特徴 \( \phi(x) \)の和は、任意の並べ替え \( \pi \)に対して変わらないので、\( f(X) = \rho (\sum_{x \in X} \phi(x)) \)が入力する順序を入れ替えても出力は変わらないことが直感的にわかるかと思います。 活用例 コーディネートデータの活用事例として、オートエンコーダーによるスタイルの抽出があります。この実験ではコーディネートを固定長のベクトルで表現する方法として、concat型とreduce型の方法を試しています。このうちのreduce型の手法は先ほど述べたpermutation invariantの条件を満たしています。この手法はコーディネートデータからスタイルを抽出するというタスクにおいて優れた性能を発揮することがわかっています。 Permutation equivariant 例えば、集合の中から仲間はずれを検知する、コーディネートデータの中からスタイルが一致しないアイテムを発見するなどの問題設定の場合、集合の入力に対して要素数分の出力が必要になります。さらに各入力要素と出力の各要素は対応関係を持っています。このような対称性をpermutation equivariantと呼び、以下のように表現されます。 ] モデルパラメータを\( \Theta\)を持つモデルを と表現した際、\( \Theta\)が を満たす変換であればpermutation equivarinatであることが示されています。さらにこの定式化の拡張として、 も、permutation equivariantを満たしています。 集合方向のmaxpoolingは入力データの順序に対して不変なので、これ自体はpermutation invariantです。 Equivariant modelのアーキテクチャ (Zaheer et al. 2017, Figure 7) このようなネットワークは、pytorchで表現すると以下のように記述することができます。PermutationEquivariantクラスが\(\Theta\)に対応する部分です。集合を扱うという新しいことができるようになっているのですが、とてもシンプルです。実際に入力の順序を入れ替えると対応した出力の順序も入れ替わることが確認できます。 import torch import torch.nn as nn class PermutationEquivariant (nn.Module): def __init__ (self, in_dim, out_dim): super (PermutationEquivariant, self).__init__() self.Gamma = nn.Linear(in_dim, out_dim) self.Lambda = nn.Linear(in_dim, out_dim, bias= False ) def forward (self, x): xm, _ = x. max ( 1 , keepdim= True ) xm = self.Lambda(xm) x = self.Gamma(x) x = x - xm return x class DeepSets (nn.Module): def __init__ (self, x_dim, d_dim): super (DeepSets, self).__init__() self.x_dim = x_dim self.d_dim = d_dim self.phi = nn.Sequential( PermutationEquivariant(self.x_dim, self.d_dim), nn.ELU(inplace= True ), ) self.rho = nn.Sequential( nn.Dropout(p= 0.5 ), nn.Linear(self.d_dim, self.d_dim), nn.ELU(inplace= True ), nn.Dropout(p= 0.5 ), nn.Linear(self.d_dim, 10 ), ) print (self) def forward (self, x): phi_output = self.phi(x) sum_output = phi_output.mean( 1 ) rho_output = self.rho(sum_output) return rho_output まとめ 今回は、集合を入力として扱うネットワークの表現のうち、permutation invariantとpermutation equivariantの2つの場合について紹介しました。入力に集合を扱えるようになることで、IQONやWEARのコーディネートデータを活用しやすくなります。例えば、コーディネートの採点やスタイルの抽出、スタイル不一致のアイテムの発見など、様々な応用例が考えられるでしょう。 さいごに 研究所ではアイテムの集合以外にも「似合う」ということについて多角的に研究を進めています。機械学習に限らず、専門性を活かしてファッションを分析できる環境を提供しています。ファッションに関する研究テーマに挑戦したい方はぜひ下のリンクから応募して、ぜひ一度オフィスに来ていただければと思います。 www.wantedly.com 参考 Han, X., Wu, Z., Jiang, Y., Davis, L. Learning Fashion Compatibility with Bidirectional LSTMs. In ACM Multimedia, 2017. Nakamura, T., Goto, R. Outfit Generation and Style Extraction via Bidirectional LSTM and Autoencoder. In KDD workshop 2018. Veit, A., Kovacs, B., Bell, S., McAuley, J., Bala, K., Belongie, S. Learning Visual Clothing Style with Heterogeneous Dyadic Co-occurrences. In ICCV, 2015. Zaheer, M., Kottur, S., Ravanbakhsh, S., Poczos, B., Salakhutdinov, R., Smola, A. Deep Sets. In NIPS, 2017.

こんにちは。新事業創造部インフラチームの光野（kotatsu360）です。 先日、VASILY時代 1 から長らく使われていたCapistranoによるデプロイを見直し、CodePipeline+CodeDeployによるデプロイフローを導入しました。 CodeDeployはEC2 AutoScalingとよく統合されており、この新しいデプロイフローによって最新のアプリケーションコードをどう反映するかという悩みから開放されました。この記事ではそのフローについて設計と運用を交えつつ紹介します。 AWS CodePipeline / AWS CodeDeploy CodePipeline AWS CodePipeline はアプリケーションのCI/CDパイプラインを作るためのサービスです。 Source 、 Build 、 Test 、 Deploy の4ステージに対して1つ以上のアクションを割り当てることで、任意のパイプラインを構築します。 設定項目が多く初めは戸惑いますが、全てのステップを使う必要はありません。 実際、今回構築したパイプラインでも Source と Deploy のみを使っています。 Build や Test に相当する部分は既存のCIで事足りるためです。 CodeDeploy AWS CodeDeploy はアプリケーションの自動デププロイを管理するためのサービスです。 エージェント式になっており、Amazon EC2だけでなくオンプレミスに対してもデプロイが可能です 2 。 デプロイの具体的な作業は、実行可能な形式で置いておきます。 # appspec.yml # CodeDeployに対してデプロイ処理を指定するファイル。リポジトリルートに置かれる version : 0.0 os : linux files : - source : / # zipに含まれるファイル全部を destination : /tmp/sample # sample以下に展開 hooks : ApplicationStop : - location : codedeploy/stop-application.sh timeout : 30 # Install: # CodeDeployが最新のコードをデプロイターゲットに配布する AfterInstall : - location : codedeploy/start-application.sh 上のappspec.ymlでは「既存プロセスをkillする」「新しいプロセスを起動する」といった内容を .sh で表現しています。これをエージェントが順次実行します。デプロイ先で実行可能であれば、表現方法は自由です。 デプロイフロー 新しいデプロイフローは次のようになりました。 画像の左下がスタートです。 アプリケーションコードがGitHub上で特定のブランチにマージされる CircleCI によるテストの後、zipで圧縮してS3に保存 S3はオブジェクトの更新をCodePipelineに通知 CodePipelineはCodeDeployを呼び出す CodeDeployは事前に定められたAutoScalingグループに対してデプロイを実行 詳細について触れていきます。 CodePipelineのパイプライン戦略 CodePipelineのデプロイパイプラインは、リポジトリ単位で分離します。 複数の役割を持っているリポジトリについては、 Deploy フェーズで分岐させ、それぞれをCodeDeployが実行します。 3 具体的には、APIのようにロードバランサにアタッチする必要のあるAutoScalingグループと、非同期処理を担当するAutoScalingグループで分離しています。 CodeDeploy + OpsWorksとの連携 CodeDeployのデプロイターゲットとしてAutoScalingグループを指定すると、新規追加されたインスタンスに対して自動でデプロイを実行します 4 。便利な一方、新規に起動したインスタンスの構成管理について考慮する必要があります。 私が管理するいくつかのサービスでは、構成管理を全てOpsWorksに集約しています 5 。これはAutoScalingグループに所属するインスタンスであっても例外ではありません 6 。 何のフォローも行わない場合、構成管理中にCodeDeployのデプロイ処理だけが先行し、デプロイが失敗します。デプロイに失敗した新規インスタンスはAutoScaling側で失敗とみなされ破棄されるため、延々と起動・失敗・破棄を繰り返してしまいます。 これを避けるため、CodeDeployよるデプロイ処理中にOpsWorks側のステータスを確認する処理を含めています。 version : 0.0 os : linux files : - source : / # zipに含まれるファイル全部を destination : /tmp/sample # sample以下に展開 hooks : ApplicationStop : - location : codedeploy/stop-application.sh timeout : 30 # この処理を追加 BeforeInstall : - location : codedeploy/setup-wait.sh timeout : 900 AfterInstall : - location : codedeploy/start-application.sh #!/bin/bash set -e OPSWORKS_INSTANCE_ID = $( grep ' OpsWorks Instance ID ' /etc/motd | cut -d: -f2 | tr -d ' ' ) /usr/local/bin/aws opsworks --region us-east-1 wait instance-online --instance-ids $OPSWORKS_INSTANCE_ID 素朴なシェルスクリプトですが、この処理を挟むことで構成管理を待った上でデプロイを実行する事ができます。 インプレースデプロイかBlue/Greenデプロイか CodeDeployのデプロイターゲットとしてAutoScalingグループを指定すると、デプロイの方法として2パターンを選択できます。 インプレースデプロイ：既存のインスタンスに対してデプロイを行う Blue/Greenデプロイ：新規のインスタンスを作成しデプロイを行う 本件では前者のインプレースデプロイを採用しています。後者の長所は障害時の高速なロールバックかと思いますが、前述の構成管理と合わせて検討すると、revertコミット＋インプレースデプロイが十分に高速かつシンプルという判断です 7 。 なお、インプレースデプロイかつデプロイターゲットがロードバランサに所属する場合、CodeDeploy側がデプロイの前後で適切にアタッチ・デタッチをしてくれます。サービスインしたままデプロイが行われるということはありません。 CodeDeployを採用してハマった事 完成した後のデプロイフローはとても安定しています。しかし、構築中にいくつかハマった部分もありました。 複数のロードバランサに所属する場合のフォロー CodeDeployは、デプロイターゲットがロードバランサ（ALBならターゲットグループ）に所属している場合、適切にアタッチ・デタッチしてくれます。しかし複数のロードバランサまでは面倒を見てくれません（2018年7月時点）。 そのため、何らかの理由で複数のロードバランサに所属するAutoScaingグループであれば、CodeDeployに渡す処理中でフォローしてやる必要があります。 #!/bin/bash set -e readonly INSTANCE_ID = $( curl -s http:// 169 . 254 . 169 . 254 /latest/meta-data/instance-id ) readonly TARGET_GROUP_INTERNAL_API = ' xxxxx ' /usr/local/bin/aws --region ap-northeast-1 elbv2 register-targets --target-group-arn ${TARGET_GROUP_INTERNAL_API} --targets Id = ${INSTANCE_ID} /usr/local/bin/aws --region ap-northeast-1 elbv2 wait target-in-service --target-group-arn ${TARGET_GROUP_INTERNAL_API} --targets Id = ${INSTANCE_ID} CodeDeployのBlockTraffic/AllowTraffic CodeDeployのデプロイは幾つかのステップがAWS側に予約されています。ロードバランサとのインテグレーションもその予約されたステップで行われるのですが、なぜか2〜3分も待たされる事があります。 どうやらCodeDeployの挙動はロードバランサのヘルスチェック設定に依存しているようです 8 。 BlockTraffic/AllowTrafficにかかる時間は次のとおりです。 Interval: 30sec 、 Healthy threshold: 10 ならそれぞれ300秒程度 Interval: 5sec 、 Healthy threshold: 2 ならそれぞれ10秒程度 運用のポリシーが許す範囲で短くしておくことをおすすめします。 CodeDeployを採用して良かったこと AutoScalingとの統合以外にもコスト面で効いた部分がありました。 集約率の向上 これはアプリケーションレベルでの Graceful Restart にこだわる必要が無くなったため得た恩恵です。 当初はAutoScalingによる柔軟なリソース配分を重視して始めた施策でしたが、改めて考えると一台あたりのパフォーマンスも上げることが可能でした。 本件で紹介しているデプロイフローを採用しているアプリケーションは Rails + unicorn + nginx という、Railsでよくみる鉄板構成です。 旧デプロイフローではunicornに対してCapistranoでUSR2シグナルによる Graceful Restart をしていました。 Graceful Restart の問題は、古いプロセスを残したまま新しいプロセスを作るため瞬間的にメモリ消費量が倍になることです。そのため、デプロイを安全に終了するためには、1インスタンス毎のメモリ消費量を40％程度に管理しておく必要があります。 一方、CodeDeployによるデプロイであれば一時的にサービスアウトしつつデプロイが進行します。そのため、既存のプロセスを一旦完全にkillできます。これによりデプロイ中という瞬間的な状態を気にすること無く集約率を検討できるようになりました。 まとめ 本記事では、CodePipeline+CodeDeployによる新しいデプロイフローについて紹介しました。 AutoScalingとの統合や集約率の向上といった恩恵はもちろんですが、デプロイを小さなステップに分割して整理できたため、保守性という意味でも向上したように感じています。 スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください。 https://www.starttoday-tech.com/recruit/ 株式会社スタートトゥデイテクノロジーズはスタートトゥデイ工務店 + VASILY + カラクルの3社を統合し発足されました ↩ AWS Lambdaに対するデプロイも可能ですが、本記事では扱いません ↩ 画像中でCodeBuildを呼び出していますが、これはパイプライン設計中に後からタスクを任せようと思った名残です。結局、既存のCircleCIで十分と気づき何もしないステージとしてそのままになっています。本記事でも触れません。 ↩ ライフサイクルフック の仕組みを用いています。 ↩ CloudFormationとOpsWorksでインフラを育てる ↩ UserData、OpsWorks、Lambdaを組み合わせ、常に新鮮なSpotFleetインスタンスでサービスを運用する （引用はSpotFleetに関する話題だが、SpotFleetでないAutoScalingでも同様） ↩ ゴールデンイメージによる構成管理時間の短縮を検討しなかったわけではありませんが、既存のOpsWorksによるフローを変更することのデメリットが遥かに大きく、早々にアプローチから外れました。 ↩ AWS Developer Forums: BlockTraffic/AllowTraffic durations ↩

（Icon Credit *1 ） こんにちは。PB開発部インフラチームの @inductor です。最近はすっかり インフラ勉強会 というオンライン勉強会の運営が趣味になっています。 今回はLambda@EdgeというAWSのサービスを使って、CloudFrontへのアクセスを「細かいルール」を設定して振り分けてみたいと思います。 Lambda@Edgeについてもう詳しく知っているよ！　という方は、次のセクションはスキップしてもらって構いません。もしよく知らないという方は、一緒に勉強してみましょう！ AWS Lambda@Edgeとは Lambda@Edge は以下の2つのサービスから成り立ちます。 AWS Lambda Amazon CloudFront CloudFrontのエッジロケーションにおいて、Lambdaで定義した任意のコードを実行できるというのがLambda@Edgeで、具体的には以下のような恩恵を得ることができます。 エッジロケーション（地域）に応じて表示させるコンテンツを変えたい User-Agentなどに応じて取得するコンテンツを変えたい アクセス元のIPアドレスによって表示させるコンテンツを変えたい 開発環境に、アクセス元IPが自社でない場合のみBasic認証を導入したい 実際に叩かれるURLと、S3などから実際に取得する資源のURIを変更したい この他にも、CloudFrontから取得できるデータに応じて様々な対応を柔軟に行えるのが特徴です。 AWS Lambdaのおさらい AWS Lambda は、任意のプログラムをサーバを用意することなく実行できるFaaS(Function as a Service)のサービスです。主に、バッチ処理やログの処理、サーバレスアーキテクチャにおけるバックエンドの処理などで利用されます。 現在Lambdaで提供されている実行環境には、Node.js、Java、C#、Go、Pythonがあり、それぞれ好きな言語を選んで実行させることができます。 詳しくは、 AWSの公式ページ や、 クラスメソッドさんなどの記事 をご覧いただければと思います。 Amazon CloudFrontのおさらい Amazon CloudFront は、AWSのCDNサービスです。世界中に存在する「エッジロケーション」と呼ばれるAmazonの各拠点に対して、S3に保存した静的コンテンツ（HTML、CSS、JSなど）をキャッシュさせておくことができます。 キャッシュのルールを細かく設定できる他、SSL証明書を ACM などから投入しつつHTTP/2の有効化やTLSのバージョン指定などのエンドポイントとしても機能的に利用できるなど、開発者にとって面倒な設定も簡単にできるという利点もあります。 改めてLambda@Edgeとは CloudFrontのエッジロケーションにおいて、Lambdaを使って細かいルールを自由に設定できるサービスです。 CloudFrontでは大きく分けて以下の4つのデータの流れがあり、それぞれ、1つのリクエスト（レスポンス）に対して一意のLambdaのコードを割り当てることができます（割り当てなくても動作はします）。 ※引用元スライド： https://www.slideshare.net/AmazonWebServicesJapan/aws-blackbelt-online-seminar-2017-amazon-cloudfront-aws-lambdaedge Lambda@Edge導入前の注意事項と事前準備 注意事項 Lambda＠Edgeにて2018年7月現在で対応しているのはNode.js(6.10と8.10)のみです Lambda関数はバージニアリージョンで作成する必要があります Lambda関数が実行されたときに吐き出されるログが保管されるリージョンは、ユーザーから 最も近いエッジロケーション になります 例えばバージニアリージョンでコードを上げていても、ベトナムのユーザーがアクセスした場合、LambdaのCloudWatchログはムンバイなどのリージョンに表示されます CloudFrontの仕様上、特定のHTTPヘッダについて書き換えられないなどの制限があります 詳しくは 公式のドキュメント へどうぞ 必要な事前準備 Lambda@Edgeを適用するためには以下の準備が必要となります。 CloudFrontとS3の準備 Lambda@Edge用のIAMロールの作成 これらについては今回は省略します。それぞれ、該当リンクなどを参考に準備をしてみてください。 まず、IPアドレスに応じて必要な振り分け先を変えるという対応をしてみましょう。 サンプルとして、以下のようなコードを作成し、Lambda@Edgeの設定をしていきます（IPアドレスはダミーのため、各自試したいものに変更しましょう）。 'use strict' const permitIp = [ '172.0.0.1' , //IPアドレスは各自設定すること！ '172.0.0.2' , ] ; exports.handler = ( event , context, callback) => { const request = event .Records [ 0 ] .cf.request; const httpVersion = request.httpVersion; const clientIp = request.clientIp; const isPermittedIp = permitIp.includes(clientIp); if (isPermittedIp) { // 許可されているIPであればそのまま次の処理へ callback( null , request); } else { // 許可されていないIPに対しては許可されていない旨のメッセージを返す const body = '<!DOCTYPE html> \n ' + '<html> \n ' + '<head><title>Hello From Lambda@Edge</title></head> \n ' + '<body> \n ' + 'Your IP address is not permitted to access! \n ' + '</body> \n ' + '</html>' /* Generate HTTP response */ const customResponse = { status : '200' , statusDescription: 'HTTP OK' , httpVersion: httpVersion, body: body, headers: { 'cache-control' : [{ key: 'Cache-Control' , value: 'max-age=100' }] , 'content-type' : [{ key: 'Content-Type' , value: 'text/html; charset=utf-8' }] , } , } ; callback( null , customResponse); } } ※特定の条件下で何もせず次の処理に渡したい場合は、上記コードのように callbackでrequestをそのまま返してあげる と良いです。 Lambdaの設定 Lambdaに対して上記コードを仕込んでいきます。 まず Lambdaのコンソール にアクセスし、関数を新しく作成します。 ※このとき、かならずバージニアリージョンを選びましょう！ 続いて、以下スクリーンショットのように関数名に適当な名前を付け、ロールに作成済みのLambda@Edge用ロールを紐づけます。 関数が作成されますので、「関数コード」の欄に該当コードを貼り付け、画面上部、右上の「保存」ボタンをクリックします。 「アクション」から新しいバージョンを発行するを選択し、「発行」をクリックします。 バージョンが1になったことを確認したら、「Designer」よりトリガーの追加→CloudFrontを選択します。 「トリガーの設定」から、ディストリビューションにCloudFrontのDistribution IDを入力し、イベントトリガーにはビューアーリクエストを追加します。 上記が確認できたら「追加」をクリックし、再度、画面右上の保存ボタンをクリックします。 CloudFrontのコンソール画面 からBehaviorsタブを選択し、「Path Pattern」にて「Default(*)」または自分の選択したいパスを選択し、「Edit」をクリックします。 最下部のLambda Function Associationsにバージョン番号含めLambda関数が紐付いていることを確認します。 最後に、該当のCloudFrontのURLをブラウザで確認します！ 該当しないIPアドレスからのアクセスに対して、以下のようなレスポンスが返ってくれば問題ないです。 以上、長くなってしまいましたが、Lambda@Edgeを使ったIPアドレスフィルタの実装手順でした。 さいごに Lambda@Edgeでは、CloudFrontだけでは今までできなかった細かいルールの振り分けが実現でき、より柔軟な使い方が可能になっています！本ブログでも、役に立った便利な使い方を定期的に更新していこうと思います。 みなさまも、この機会に是非導入を検討してみてはいかがでしょうか！ スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ https://www.starttoday-tech.com/recruit/