iOSDC Japan 2018 に2名が登壇&ブースでお待ちしております!

こんにちは!広報部のとくなり餃子大好き( id:tokunarigyozadaisuki )です。

毎日異常気象が続いていますね。猛暑に豪雨…みなさん、体調管理には十分気をつけてくださいね。

さて、iOSと周辺技術を題材としたカンファレンス、iOSDC Japan 2018が今年も8月30日(木)〜9月2日(日)に開催されますね!

クックパッドは、昨年同様プラチナスポンサーをさせていただいておりますので、ブースを出展いたします。また、弊社エンジニア@giginet@slightairが登壇し、@sgr-ksmtが当日スタッフとして関わってくれます。カンファレンスには、他にも多くの社員が参加いたしますので、会場でクックパッド社員をお見かけの際には、お声がけいただけますと嬉しいです。

登壇スケジュール

クックパッドの社員2名は、カンファレンスの3日目と4日目に登壇いたします。 以下、スケジュールと登壇内容のご紹介です。

3日目 9月1日(土)

11:20〜 Track A 三木 康暉(@giginet ):詳解Fastfile

プロジェクトが大規模化していくと、さまざまな業務を自動化したくなってきます。同時にロジックが増え、特定の人しかメンテできなくなったFastfileにお悩みの方も多いでしょう。 このトークでは、実際の活用事例を交えながら、大規模プロジェクトにおける効果的なFastfileの書き方、プロジェクトの雑務自動化についてをお話しします。 そのほか、fastlaneコミッターによる明日から使える実践的なtipsも数多くお伝えします。

コメント

Fastfileについて30分も何を話すんだ、と我ながら不安ですが、なかなか他所で聞けない知見を盛りだくさんにしたいと考えていますので、fastlaneを運用している方だけではなく、業務改善に興味がある方全てに役立つ内容にしたいと思っています!

16:20〜 Track C 茂呂 智大(@slightair):動作確認のための社内アプリ配信サービスを新たに作った話

アプリの開発中にビルドしたアプリをCrashlyticsBetaやDeployGateなどにアップロードし、手元で動作確認できるようにしているチームは多いと思います。 僕たちもそういったサービスを使ってきましたが、様々な課題が出てきたため自分たちの使い方にあったシステムを新しく作りました。 どういった課題がありどういうツールを用意したのか、そしてどうリリースフローが改善されたか話します。

コメント

組織に合わせてどういう仕組みやツールを用意したのか、それによってどう開発環境を改善できたかという話ができればと思っています。がんばります。

4日目 9月2日(日)

16:10〜 Track A 三木康暉(@giginet ):🀄

Swiftの様々な言語機能を使って麻雀を遊んでみましょう! Swiftyな麻雀ライブラリの実装や、和了判定のアルゴリズムなどについてお話しします。

コメント

最終日の最後で、皆様お疲れだと思うので、頭を使わずに聞けるLTになると良いなと思います。僕はすでに準備で疲れています。

ブース

iOSDC Japan 2018 では、ブースの出展をいたします。グッズの配布はもちろんですが、今回は、みなさんに楽しんでいただける特別プログラムを予定しておりますので、乞うご期待……! ぜひ、お立ち寄りくださいね。

おわりに

発表内容へのご質問やクックパッドにご興味をお持ちの方は、お気軽にブースまでお越しください。みなさまにお会いできることを楽しみにしております。

【開催レポ】Cookpad Tech Kitchen #16 コメルコテックバナシ〜新規事業開発のリアル〜

こんにちは。広報部のとくなり餃子大好き( id:tokunarigyozadaisuki )です。

2018年7月19日に、Cookpad Tech Kitchen #16 コメルコテックバナシ〜新規事業開発のリアル〜を開催いたしました。クックパッドでは、Cookpad Tech Kitchenを通して、技術やサービス開発に関する知見を定期的に発信しています。

f:id:tokunarigyozadaisuki:20180803144413j:plain
ホワイトボードと発表練習中の星川

第16回は2018年6月26日にリリースいたしました、料理が楽しくなるマルシェアプリ「Komerco-コメルコ-」の開発裏話をテーマとし、Firebase, Algolia など利用している技術の話はもちろん、新規事業のサービス開発について、デザインの観点からもお話をさせていただきました。 本ブログを通してご来場いただけなかったみなさまにも、当日の様子をお届けしたいと思います!

料理が楽しくなるマルシェアプリ「Komerco-コメルコ-」

f:id:tokunarigyozadaisuki:20180802173546p:plain

「モノとの出会いで、料理はもっと楽しくなる」

「Komerco-コメルコ-」は、料理道具、うつわ、カトラリー、リネン雑貨などの“料理が楽しくなるモノ”が買えるマルシェアプリです。自身の手で創るモノで「料理を楽しんで欲しい」と願うクリエイターさんが出品した作品を、スマートフォンアプリから直接購入することができます。また、作品のこだわりやストーリーを紹介する「コメルコバナシ」などの記事コンテンツも提供しております。 みなさんもぜひアプリをダウンロードして、とっておきのモノを見つけてみてくださいね!

Komerco - コメルコ - by クックパッド

Komerco - コメルコ - by クックパッド

  • Cookpad Inc.
  • ショッピング
  • 無料

発表プログラム

「Komerco-コメルコ-を支える技術」

はじめに、2017年に中途入社したiOSエンジニアの星川より「Komerco-コメルコ-を支える技術」というタイトルで、「Komerco-コメルコ-」で利用している技術についてお話しいたしました。

「Firestore と Cloud Storage を用いたアプリでの画像の扱い方」

2017年に新卒でクックパッドへ入社した三浦からは、「Komerco-コメルコ-」でのユーザーから投稿される画像の圧縮やリサイズに関して、サンプルアプリを用いながら画像の投稿、取得フローについてご紹介しました。

「Effective Firestore Security」

2017年に中途入社したiOSエンジニアの岸本からは、Firebase Cloud Firestoreの "セキュリティ" に焦点を当てて、問題となるケースの紹介、セキュリティを意識したモデル設計、セキュリティルールの実践的な書き方をお話させていただきました。

「ゼロからはじめるサービスのデザイン」

2017年から新卒でクックパッドへ入社し、現在「Komerco-コメルコ-」のリードデザイナーとしてブランディングからサービスの体験、Web・アプリのUIなどデザイン全般と開発を担う藤井からは立ち上げからリリースまで、サービス全体のデザインを見るにあたって取り組んだことや、仕組みづくり、デザインの観点からサービス開発のリアルをお話いたしました。

付箋形式でお答えするQ&Aディスカッション

Cookpad Tech Kitchenでは参加者のみなさまからの質問を付箋で集めています。 ほんの一部ではありますが、当日は下記のような質問に回答いたしました。

f:id:tokunarigyozadaisuki:20180802173252j:plain
たくさんのご質問ありがとうございました!

Q: Firestoreのデメリットは?
A: スキーマが無い。エクスポート出来ない(分析の為にスクリプトで対応している)

Q: Cloud Functionsでの失敗をどの様にハンドリングしている?
A: 不整合のあるデータを集めてきて一括でパッチするスクリプトがある

Q: rulesを書きはじめるタイミングは?
A: 最初は緩かった。リリースする数ヶ月前ぐらいからでもよいのでは。とはいえ最初から書けるなら書いた方が良い

Q: rulesを書けなかったのはどういう時?
A: 制限がある。リスト、マップの中の値が何かをチェック出来なかった。他のコレクション・ドキュメントを参照したり出来なかった。お金に関する部分はCloud Functionsに寄せている

Q: UIから直接モデル(Firestore)を操作していましたが、テストはどうしていますか?
A: 外部のモデルフレームワークに則っているからそっちで任せている。モデルに実装を寄せると自由度が落ちる

f:id:tokunarigyozadaisuki:20180802173259j:plain

シェフの手作り料理

Cookpad Tech Kitchen ではイベントに参加してくださったみなさまにおもてなしの気持ちを込めて、シェフ手作りのごはんをご用意しております!食べながら飲みながらカジュアルに発表を聞いていただけるように工夫しています。今回お越しいただけなかった方も、ぜひ次のイベントはご参加くださいね。

f:id:tokunarigyozadaisuki:20180802174125j:plainf:id:tokunarigyozadaisuki:20180802234907j:plain
オリジナルロゴ寿司ケーキとシェフ特製の料理

f:id:tokunarigyozadaisuki:20180803080331j:plain
乾杯の様子

おわりに

クックパッドではKomerco事業部はもちろん、その他新規事業、レシピサービス事業などに携わる新しい仲間を募集しています。ご興味がある方はぜひご応募ください!お待ちしています。

www.wantedly.com

http:// https://info.cookpad.com/careers

次回のCookpad Tech Kitchen のテーマは「北欧で最新のインタラクションデザインを学んできた話」。8月22日 (水)に開催予定です! クックパッドでは他にも様々なイベントを企画しておりますため、今後のイベント情報についてご興味がある方は、ぜひConnpassのメンバー登録をポチっとお願いいたします!みなさまにお会いできることを楽しみにしております。

cookpad.connpass.com

Chaos Engineering やっていく宣言

技術部のヨシオリです。

Netflix が Chaos Engineering の論文を公開して 2 年ほど経ちました。
クックパッドは最近、 Chaos Engineering を導入する事を決めました。
この記事ではその背景を紹介したいと思います。

そもそも Chaos Engineering とは

Netflix では Failure Injection Testing として、営業時間中に意図的に障害を起す事をやっていました。Chaos Monkey というインスタンスとサービスを落すものから Chaos Gorilla、Kong という availability zone や region 単位で障害を発生させるものなどです。

その経験から Chaos Engineering というものが提唱されました。
Principles of Chaos Engineeringによれば

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

と定義されています。
意訳すると「本番環境の分散システムが過酷な状況でも耐えれるとの確信を得るために、実験するという取り組み」とかでしょうか?

分散システムはマイクロサービスと置きかえるとイメージしやすいと思います。複数のマイクロサービスが相互に呼び出し、協調して動くシステムでは一つのサービスがクラッシュしただけでシステム全体が壊れるような事になっていてはいけません。そうなると、ユーザーに届けられる価値が減ってしまいビジネス的にも問題です。
もちろんそうならないように作るべきですが、それでも予想不可能な事は起こります。それを知るためにコントロールされた障害を投入し、知見を広げたり、確信を得たりするのです。

そのための実験は下記のステップで進めます。

  1. 正常な振る舞いをしているかどうかを測定可能な値として定義する。
  2. この正常な状態が通常時と障害エミュレート時の両方で継続することを仮定する。
  3. サーバクラッシュ、ディスク異常、ネットワークエラーなどの現実世界で起こりえる障害をエミュレートする。
  4. 1で定義した値を通常時と障害エミュレート時で比較し検証していく。

詳しくは上記論文やリンク先を見ていただくとして、凄くザックリと纏めてしまうと、
システムにコントロールされた障害をエミューレートし、それでも壊れない事を検証していく
と、思ってもらえれば良いかと思います。
元々、昔から似たような事をやっているサービスはありましたが Netflix がそこに Chaos Engineering と名前と付け原則などをわかりやすく纏めた感じですね。

必要になった背景

クックパッドでは 2014 年ころからマイクロサービスに取り組んで来ました。

そして個々の Web アプリケーションはコンテナ技術で仮想化し、コンテナオーケストレーションツールとして ECS を使い運用しています。

また、サービス間の通信に関してもサービスメッシュの導入などを行なっています。

その結果、今ではチーム数も増加し、開発規模も大きくなっています。結果として( 管理画面を提供するサービスなどを除いても) 大小 80 個近くのサービスがそれぞれお互いに緩くではありますが連携し動いています(僕も数を調べてビックリしました)。

さすがにこれだけのサービスが連携して動いているとどこかで発生した障害がどこまで影響するのか把握するのは容易ではありません。
A というモバイルアプリが叩いている B という API の裏で通信している C が必要としているデータ取得のための D のレスポンス時間が遅くなって、結果として A の応答が悪くなったのだが、原因が D だとは思っていなかった……的な事も発生します。

何故やるのか

上記ブログのマイクロサービス導入背景にもありますが、昔のようにひとつの巨大なアプリケーションを運用するようなスタイルではプロダクト開発の規模の拡大やスピードに限界があり、マイクロサービスアーキテクチャを採用するようになりました。分散システムとして Web サービスを実装する事により単一の複雑なアプリケーションからは開放されましたが個々のサービス間の連携は複雑になりました。

Chaos Engineering の導入によってサービスの耐障害性に自信を持てるようにします。日常的に障害をエミュレートする事によってサービスの耐障害性が高いことを開発者に要求します。
ソフトウェアテストなどの文脈では良く言われますが、不具合は発見が遅れれば遅れるほど、その不具合を修正するコストはかさむことになります。
可用性の高いシステムを作るために、不具合を早く発見し改善していくために Chaos Engineering を導入していきます。

付随して考えている事

人は自分が想像出来るものにしか対処出来ません。バグというのは大体が想定外の入力によって発生します。そこでもっと想像力を働かせろ的な精神論を言っていても良くはなりません。Chaos Engineering のように実際にそういった状況を作る事が大事だと思っています。
例えばクックパッドでは各サービスがどんどん AWS の Spot インスタンスで動くように移行していっています。これはサーバはいつ落ちても良いようにしておかなくてはいけないし、バックグラウンドジョブは落ちたら再実行出来るようにしておかなくてはいけない事を開発者に強制します。
でも、それらは実は Spot インスタンスで動くからやらなければいけないものではありません。耐障害性の高いシステムを作るためにはやらなければいけない事を Spot インスタンスの環境にする事によって強制するようになっただけです。
さきほども書いたように人は自分が想像出来るものにしか対処出来ません。Chad Fowler が Immutable Infrastructure を提唱したけれども、開発者がそれを真に実行出来るようになったのは Docker という環境のおかげというのと同じです。

最後に

現在、クックパッドでは Hako や ECS を使ったコンテナ環境の整備が進み、サービスメッシュの導入によりサービス間の通信を集中管理出来るようになりました。これにより、Envoy proxy を利用してサービス間通信で障害をエミュレートしたり、それらの設定を hako で行えるようになったりと環境は整いました。
まだまだクックパッドのマイクロサービス群の正常な状態( steady-state )をどう定義していくかなどやらなければいけない事は色々あります。
個人的にはこの規模のマイクロサービス群を扱っていく環境は国内ではそんなに多くはなく大変面白い環境だと思ってます。
クックパッドでは一緒に Chaos Engineering を導入していく仲間を募集しています
このエントリを読んでご興味をお持ちいただけた方は、ぜひともご応募ください。