Japan Container Days v18.12 参加レポート

f:id:yu_suke1994:20181205140614j:plain

12月3日から5日にかけて、Japan Container Days v18.12が開催されました。弊社からは、業務扱いで id:yu_suke1994id:fujikawa-y の2名が参加しました。今回はその参加レポートになります。

多くのセッションに参加しましたが、その全てに言及するととんでもなく長い記事になってしまいそうなので、印象深かったセッションに絞って感想を書いていこうと思います。

keynote

keynoteでは、複数の企業におけるKubernetesの役割などについて話されました。

CNCFのChris Aniszczyk氏からは、CNCFの目指す地点、今後のロードマップなどについての話がありました。Serverlessだけではなく、Nodelessへの流れ、KubernetesをIoTやedge computingの世界まで広げたいという野望、kubeletそのものを仮想化するvirtual-kubeletの紹介などがありました。

github.com

またCNCFで定義している各プロジェクトの成熟度合いも確認することができるようです。

Projects - Cloud Native Computing Foundation

1年間の本番運用でわかったコンテナがチーム開発にもたらしてくれたもの


本番環境でコンテナを使うという事例を話されていました。

そもそもなぜコンテナ化をするのか?というところから言及されており

  • 開発環境を快適にしたい
  • 開発環境と本番の乖離をなくしてサイクルを早くしたい

これに尽きるのは納得の行く話でした。

そして、途中で口頭であった 心理的安全性を保つためにコンテナ化 というのが印象深かったです。

40 topic of Kubernetes in 40 minutes


マイクロソフトの寺田さんによる、40分でKubernetesにおけるトピックを40紹介する、という駆け足の発表では、 $ kubectl explain というコマンドの存在に衝撃を受けました。今までは https://kubernetes.io/docs/reference/#api-reference を見ながらYAMLを書いていたのですが、このコマンドがあればわざわざブラウザを使わずともYAMLにどのようなリソースの定義を記述できるのかがわかるので便利だと思いました。

1人でできるDocker/Kubernetes(GKE)を使った新規サービス立ち上げ


DeNAの新規サービス立ち上げにDocker/Kubernetesを使われた話が聞けるということで聞きに行きました。

最初からRailsで行くことのとチャレンジングなところでコンテナを使うという話があり 少人数でサービスを作るノウハウと過去の開発で課題だったことが印象深かったです。

また、サーバー側とインフラ側で担うところも明示的に示しておりとても参考となりました。

2020年のコンテナはどうなる!? コンテナプラットフォームのこれまでとこれから

コンテナ界隈の人たちを呼びこれからどうなっていくかを話されていまいした。 いくつかの議題があり、それに対するコメントのうち印象に残ったものを抜粋して記載します。

  • コンテナ技術浸透した?
    • 浸透したと思う理由
      • 来場者のアンケート回答結果の9割が使っているというのがあり、自分で調べられる状況にある
      • 普及はしているが、本番はこれからという印象
    • コンシューマ向けサービスの開発はβ版でも使っている
      • 開発、CICDもやっているが本番はやはりまだ少ない
    • 浸透したと思えない理由
      • 詳しい人とまったく詳しくない人の二極化が目立っている
      • 使えるけど、メリットに繋げられない人も多く感じている
      • エンタープライズには話が通じないのが現状
      • さらに概念を理解せずに使っている印象がある
    • どこがネック?
      • コンテナをコンテナらしく使うことが今後の課題
      • コンテナを使うからこその付加価値が必要
    • コンテナは何が動くのか?ということもありまた、マイクロサービスの定義にも繋がってくる
      • マイクロサービスは組織の問題も関わってくる
      • アプリケーションレイヤーのI/Fだけ連携する
        • その中の話はチームに権限委譲して自律的にやってもらうのが良い
    • システムを組織に合わせるのが今の日本の組織。
    • Webサービスなら導入できるが、エンタープライズはハードルが高く慎重である
    • 本番導入済のところはマネージドサービス使われているのが前提であって、自前で動かしている人は考えることが多すぎて本番に導入できないのではないか?というところがある
  • k8sデファクトスタンダードになっているが差別化は?
    • k8sの導入、運用、カスタムができるという差別化となる
    • k8sの全部の機能いります?という疑問に行き着くところもあり、他のやつを使った方が良い場合もある
    • 更に言うとコンテナ使えるだけいいのでは?ということも言える
    • Runcherもk8sとの差別化を意識しつつ使う人が幸せになるようにしたい
    • k8sの良さは拡張性があること
    • k8sのデプロイとバージョンアップが大変
      • また初期の学習コストが高くアプリデベロッパーへどう浸透させていくのか?が課題。
  • 今後追うべき技術は?
    • Knative
    • サービスメッシュが来る。Istioがきて成熟期になる
    • イベント情報をキャッチアップすることが大事
    • CoreOSも追うべきもので、それも含めて運用を楽にするためのもの
    • AIのKubeflowでデータパイプラインが必須な部分なのでこれも追う

Cloud Nativeプロダクト1000本ノック

CNCF Landscapeには、CNCFでないプロダクトも含め、600を超えるプロダクトが掲載されています。

landscape.cncf.io

このセッションでは、データストア、CI/CDなどのトピックに分けて主要なCNCFプロダクトの紹介が行なわれました。辛うじて名前だけ聞いたことがあったりするものや、初耳なプロダクトも結構あって、こんなの追い切れないだろう……と思いました。だからこそ、コミュニティとして活動し、様々な検証を持ちよって情報を共有し合うことが重要になるのですね。

また、Cloud Native Trail Mapを見るとわかるのですが、コンテナ化、Kubernetesによるオーケストレーションは "Cloud Native" という観点ではまだ入口に過ぎず、そこで満足していてはいけないのだなということも感じされられます。(プロダクトの規模にもよるとは思いますが……)

また、このセッションで知ったのですが、Spinnakerがpipelineをコードで管理できるようになっていたのには驚きました。それまではGUIによるpipeline定義しかできず、.circleci/config.yml のようにコード化できないのはちょっと、なーと思っていたところなので、導入に向けて前向きになれますね。

blog.spinnaker.io

pipelineの定義については、イベントでデモとして提供されていたshowKs( https://showks.containerdays.jp/ )で実際に使用されているものがGitHubで公開されています。

github.com

runcだけじゃない コンテナlow level runtime徹底比較


皆さんはコンテナのruntimeを意識してDockerを使っていますか?僕は全く意識していません。

Dockerは、コンテナのruntimeとして、デフォルトでruncというものを使用します。このruntimeは実は様々な特性のあるものが公開されているのですが、よっぽどのことがない限りはruncから変更することはないでしょう。

このセッションでは、そんな様々なruntimeの紹介と、それに対してのベンチマークを行い、その結果や選択の指針についての発表が行われました。 紹介されるruntimeはどれも特色にあふれ、技術的好奇心を刺激されはするのですが、じゃあproduction環境で使いますか、となるとそこまでのメリットは感じられない、と言うか一般的なユースケースにおいてrunc以外をあえて使うことって無いよな……と感じました。Nabla containersとか、うおお何じゃそれ! とはなるんですけどね……

とある30秒でできるKubernetes + GPU 開発環境


Canonicalの方による、 https://microk8s.io/ の紹介LTがありました。microk8sは初耳でしたがsnap packageになっており、Ubuntuユーザーの僕としては何ならMinikubeより導入が楽なのでは?という気さえしました。会場にいた方のなかには、「Minikubeはなにやってるかわからなくて若干ブラックボックス感があるのでmicrok8sのほうが好きだ」と言う意見もあり、ローカルでもKubernetesで開発する際にはぜひ使ってみたいと思いました。

CRIUの概要とその活用 - 未来のコンテナ技術について


GMOペパボにて、mrubyによるコンテナランタイムhaconiwaを開発していらしゃるうづらさんの発表でした。今回はhaconiwaの話ではなく、CRIUの話でした。

皆さん、 $ docker checkpoint というコマンドをご存知でしたか?僕はこの発表で初めて知りました。CRIUは、checkpoint/restore という機能を実現するためのツールです。利用することで、あるプロセスのその時点でのsnapshotを取得でき、その情報からプロセスの状態を復元することができる、ということが可能になります。

デモでは、whileループでカウントアップしていく変数の状態が、$ docker checkpoin crerate$ docker start --checkpoint の前後で保持されていることが確認できました。

docker v18以降では、checkpointはうまく動かないようですが、これが安定して動作するのであれば夢が広がりますね。例えば規模の大きなRailsアプリケーションは、起動に若干の時間がかかり、突発的なスケールには対応できません。これが、起動後の状態のcheckpointを作成しておき、それを展開することによって素早いスケールアウトができるようになったりするでしょう。

Runtime BoF

docs.google.com

ディスカッション形式でruntimeについて話すTechMeetingでは、第一線で活躍しているエンジニアの方々による、runtimeに限らない様々な議論について聞くことができました。 先程も書きましたが、結局runtimeをruncでないものにするメリットってあるんだっけ、という話から、コンテナイメージのセキュリティの担保、はたまた海外でのカンファレンスやOSS開発における英語問題など、本当に議題は様々でした。

コンテナイメージのセキュリティに関しては、とても考えさせられました。Docker Hubで個人が公開しているimageは使用しないというのは前提として、企業が公開しているimageであっても、それに悪意のあるコードが混入していないという保証はありません。imageに署名をするよりは、継続的なimageのスキャンのほうが重要である、という意見がありました。CNCFにも、そのようなことを行なってくれるClairというものがあります。またGCPにも、Container Analysisという機能があります。積極的に使っていきたいですね。

感想

非常に濃いイベントでした。便利そうなCloudNative productの情報であったり、Kubernetes運用の知見であったり、他の企業がどうしているのか、今後のCloudNativeの方向性、などなど……情報量で圧倒されました。今年は、聞くことのできなかったセッションのスライドを読んだりして、内容を噛みしめたり、書籍を読んだりして、今後のサービス開発に役立てられることがないか考えることにしようかと思います。

また、今年2回目となるJapan Container Daysですが、今回で最後となることが発表されています。ですが、CloudNative Daysと名前を変え、来年には東京だけでなく福岡や大阪でも開催されることが同時に発表されました。しかも福岡開催はRubyKaigi2019の直前ということで、僕は個人的にめちゃくちゃ盛り上がっています。

https://cloudnativedays.jp/

CloudNative、やっていきましょう。

sidekiq-cronアップデートへの道のり

f:id:yu_suke1994:20181121141855p:plain

こんにちは。ジョブスケジューラーとしてはSidekiqしか触れてこなかった うなすけ (id:yu_suke1994) です。

さて、Railsアプリ開発者の皆さんは定期的な bundle update を何らかの方法で実行していることでしょう。弊社でも最近になって Dependabot を導入することになりました。

今回は、Dependabot を導入する前に、一気に bundle update したときに起こった Sidekiq まわりの問題、それも sidekiq-cron で起こった問題について書いていこうと思います。

「一気に bundle update」 とは何か

弊社サービス、特に今回はCASHのAPI サーバーのRailsについての話になりますが、これまでは気付きベースで bundle update を行なってきました。

さすがに自動でやっていく仕組みを入れたいので、ツール導入のためにもう一度 bundle update を実行し、今後はツールによる差分のみを注意して見ればいいという状況に持っていくことにしました。1

問題なく bundle update できた……と思っていた

f:id:yu_suke1994:20181120171335p:plain

updateされるgemのコードを確認し、staging環境での動作確認も行ない、特にエラーもなかったのでmergeしてdeployしたのですが、本番ではJobの実行時に例外が発生するようになってしまいました。

なぜCronJobは実行されなかったのか

sidekiq-cron は、CronJob が最後にenqueueされた時刻をRedisに保存します。 v0.6.4 でのコードは以下のようになっています。

#enque cron job to queue
def enque! time = Time.now.utc
  @last_enqueue_time = time

https://github.com/ondrejbartas/sidekiq-cron/blob/v0.6.3/lib/sidekiq/cron/job.rb#L47-L74

ここで、 Time.now.utc の結果は、このまま to_s されてRedisに保存されます。

さて、 Redisから最後に queue に入った時刻を取り出す部分の v1.0.4 でのコードが以下のようになっています。

def parse_enqueue_time(timestamp)
  DateTime.strptime(timestamp, LAST_ENQUEUE_TIME_FORMAT).to_time.utc
rescue ArgumentError
  DateTime.strptime(timestamp, LAST_ENQUEUE_TIME_FORMAT_OLD).to_time.utc
end

https://github.com/ondrejbartas/sidekiq-cron/blob/v1.0.4/lib/sidekiq/cron/job.rb#L554-L558

そして、 LAST_ENQUEUE_TIME_FORMAT_OLDLAST_ENQUEUE_TIME_FORMAT は次のようになっています。

LAST_ENQUEUE_TIME_FORMAT = '%Y-%m-%d %H:%M:%S %z'
LAST_ENQUEUE_TIME_FORMAT_OLD = '%Y-%m-%d %H:%M:%S'

https://github.com/ondrejbartas/sidekiq-cron/blob/v1.0.4/lib/sidekiq/cron/job.rb#L15-L16

この辺で勘のいい方は気づかれるかと思いますが、Redisからの last_enqueue_time をparseする際、書式が想定外だと例外が上がります。

つまり、 Time::DATE_FORMATS[:default] を独自定義していた場合、 sidekiq-cron v0.6.4 時代に実行されたCronJobは v1.0.4 にアップデートすると実行できずに例外が上がってきます。

そして案の定、CASHのAPIサーバーでは Time::DATE_FORMATS[:default] が再定義されており、前述の挙動によって sidekiq-cron v1.0.4 が動作しませんでした。

アップデートするためにやること

このとき、無事に v1.0.4 にアップデートするために取り得る手段として、次の3つが候補としてありました。

  1. 正しい書式の時刻をRedisに格納し直す
    • 独自定義した書式からは時刻単位の情報が欠落しているので復元が不可能
    • Redisの値を手で操作したことがなく、不安
  2. sidekiq-cronで使用している key-value の組を全部削除する
    • これまでの実行情報が全て消えてしまう(が、そもそも正確ではないし……)
  3. 独自定義を削除し、正しい書式でRedisに格納されるまで待つ
    • 時間はかかるが安全

ということで、「独自定義を削除し、正しい書式でRedisに格納されるまで待つ」ことにしました。CronJobのなかには、毎月1回実行されるというものがあります。なので、 Time::DATE_FORMATS[:default] の設定を削除してから1ヶ月待ち、Redisに格納されている last_enqueued_at の書式が全て正しいものになっているかどうかを確認したうえで、sidekiq-cronのアップデートを行いました。

まとめ

という訳で、継続的bundle updateの体制が整いました!流れでRailsのバージョンも5.2.1になりました。

引き続き、やっていきましょう。


  1. 今考えると、そのようなことをする必要はなかったんじゃないかと思いますが……

【開催レポ】BANK engineer night #02 〜狂ったようなことをしよう〜

こんにちは。BANK広報の磯田です。

2018年10月11日に『BANK engineer night #02 〜狂ったようなことをしよう〜』を開催いたしました。BANKではBANK engineer nightを通してBANKのメンバーが、普段どのようにスピリットを持ちながらサービスを開発しているのかを、 多くの人に知ってもらいたい、という想いから今回のイベントを企画いたしました。 f:id:bankinc:20181030102342j:plain

現在BANKは、『CASH』と『TRAVEL Now』の2つのサービスの開発・運営を行なっています。 今回のイベントでは、2つのサービスを世に出し、育てていく上で、いかに狂ったように振り切ってきたのかをエンジニア4名がLTでお話しました。

眼の前のアイテムが一瞬でキャッシュに変わる『CASH』 https://cash.jp/ f:id:bankinc:20181030105011p:plain

あと払い専門の旅行代理店アプリ『TRAVEL Now』 https://travel.app/ f:id:bankinc:20181030105014p:plain

発表プログラム

CEO光本からご挨拶

はじめに、CEO光本からみなさんにご挨拶です。会社紹介と、運営している2つの事業についてお話させていただきました。 『エンジニアがうらやましい。まだ世の中に無いサービスを作り出すことができるから。』という話をしていて、みなさん深く頷かれていました。 f:id:bankinc:20181030102258j:plain

魅力品質をアゲて見たことないサービスを認知してもらう

iOSエンジニアの高橋からは、今回初めて開発秘話が話される「TRAVEL Now」のお話でした。 f:id:bankinc:20181030102447j:plain

speakerdeck.com

ユーザーの心をつかむ「魅力品質」と絶対に必要な「当たり前品質」の両方を落とさずに、新規事業の開発についてお話しました! 今までにないサービスを世の中に出すことは、受け入れられるのか怖いけど、だめならブラッシュアップして直せば良いという気持ちで開発に臨んでいたそうです。

スピード狂エンジニアたちの開発速度を保つインフラとは

サーバーサイド兼インフラエンジニアの高橋からは、スピードのお話。 f:id:bankinc:20181030102453j:plain

speakerdeck.com

入社してからどんどんメンバーが増えていく中で、数人規模で開発していたときのスピード感を落とさずに開発できる環境を整えたお話でした。 「インフラはあくまで裏方」という言葉が印象的でした!

なぜBANKは名刺でお金をばらまくのか

Androidエンジニアの遠藤より、名刺でお金をバラまいたお話をさせていただきました。 f:id:bankinc:20181030102323j:plain

speakerdeck.com

なぜ名刺なのか。おもしろさと有用性の伝え方を開発者目線からお話しました。 遊び心を忘れないバンクのエンジニアらしいアイデアですね。

Knativeで限界突破 〜Push通知をバラ撒くために〜

サーバーサイド(Ruby)エンジニアのうなすけからもバラまきのお話。こちらは「Push通知」をバラまいたようです。 f:id:bankinc:20181030102321j:plain

speakerdeck.com

CASHのユーザーに数十万件単位で送ったプッシュ通知についてお話しました。 実際に会場で、デモをして盛り上がりました!

懇親会

バンクの他のメンバーも応援に来ていたので、参加者のみなさまとお話することができました!スペースがいっぱいになるくらいの人に来ていただき、懇親会もとても盛り上がりました。 f:id:bankinc:20181030102311j:plain

おわりに

今回のイベントでは、『CASH』と『TRAVEL Now』の開発秘話についてご紹介いたしました。 BANKメンバーがどんなことにこだわり抜いて、狂ったようにサービスを育てているのか伝わるイベントになっていたら幸いです! BANKでは、サービス改善や新規事業に向けて日々取り組んでいるところですが、実現したいことに対して、まだまだ力が足りていません。そこで、一緒に新しいことをやっていただけるメンバーを探しています。

bank.co.jp

f:id:bankinc:20181030102318j:plain

https://bank.co.jp/recruit/

bank.connpass.com

今後のイベント情報についてはConnpassページについて随時更新予定です!イベント更新情報にご興味がある方は、ぜひメンバー登録をポチっとお願いします!

Google Cloud NEXT'18 in Tokyoで登壇しました

f:id:yu_suke1994:20180920144234j:plain

こんにちは。発表では早口になりがちなうなすけ (id:yu_suke1994) です。

さて、以前の記事でも告知していましたように、弊社高橋 (id:takutakahashi)、Google Cloud カスタマーエンジニアであるSokoPさんと共に弊社におけるGCPの活用事例について Google Cloud NEXT'18 in Tokyo で発表してきました。

当日お越し頂いた皆様、本当にありがとうございました。

発表内容

発表スライド、録画は以下になります。

発表については、大きく3つのテーマに分けて話しました。詳しくは資料、もしくは録画を参照していただくとして、簡単に発表した内容についてまとめます。

インフラについて

インフラについては、「開発スピードを最大化させるインフラ」を目指しています。 検証環境を複数立ち上げる、そしてそれを可能な限り早く行なうために ingress-gce をやめて nghttpx ingress controller を採用したり、CI上での docker build とテストを並列実行させたりという、様々な取り組みについて話しました。

アプリケーションについて

様々な「実験」を行なうときに、どのようにGCPのリソースを活用して素早く結果を得られるようにしたか、また開発を進めていくと生じる障害や不整合に対してどのように対処するか、などについて話しました。

開発体制について

成長していく開発組織の足止めを最小限に抑え、新メンバーが素早く開発に参加していけるようにどのようなことを行っているのかについて話しました。

発表してどうだったか

こちらから応募したとはいえ、このような規模のイベントで話す機会はこれまでになく、とても緊張しました。

規模の大きなイベントなので、6月中旬から準備が始まっています。プロフィール提出やスライド作成のための打合せ、実際のスライド作成と通しでの読み合わせなど、いい発表をしたいという思いで結構なリソースを割いて準備しました。発表後、SNSでの反応を見ていると、結構好印象だったのでとても嬉しく、苦労が報われる思いでした。

これから

発表した内容でもっと詳しく「やってやったぞ!」を伝えていきたい内容、とくにインフラに関しては今後ブログに投稿していきたいと思っています。

また、来年のGoogle Cloud NEXTでも採択されるような発表ができるよう、日々切磋琢磨していきたいですね。やっていくぞ!!

f:id:yu_suke1994:20180920152029j:plain

我々はそんなやっていく気持ちがあるエンジニアを募集しています。興味がありましたら、是非お気軽にご応募ください。

bank.co.jp

TRAVEL Now Androidアプリがリリースされました!

f:id:YousukeTezuka:20180927145006p:plain

こんにちは、BANKでAndroidエンジニアをしている手塚です。

Androidユーザのみなさんお待たせしました!昨日TRAVEL NowのAndroidアプリがリリースされました!
これから紅葉など季節の移ろいがたくさん感じられる季節になりますね!ぜひTRAVEL Nowを使って旅行へ行ってみてください!

さて本記事では、TRAVEL Now Androidアプリではどんな技術を採用して開発してきたのか一部ですが紹介していきたいと思います!

言語 & 開発環境

100%Kotlinで書かれています。もうJavaを書けない体になってしまいました。
coroutineなどはまだ使えていないため、適切な場面があれば積極的に使っていきたいです。

IDEはアプリをリリースするころにはさすがにStableになってるだろうと 判断して 高を括って、約3ヶ月前に開発を開始した時点からAndorid Studio 3.2を使って進めました。
結局リリースまでにStableにならなかったなと思いながらテストしていましたが、まさかリリース前日にStableになるとは...。

アーキテクチャ

これまで開発してきたアプリではMVVMで書くことが多かったのですが、ViewModelがややfatになってしまうのが悩みで今回はFluxを採用してみました。
現段階では各コンポーネントの責務がより細かく明確でデータフローも単方向になり見通しがよくなった一方、当然ですがクラス数コード数がやや増えたかなといった印象です。
一長一短といった感じで自分の中でもまだまだ試行錯誤中なので、もう少し知見が溜まったらまた発信したいと思います。

デザイン

Material Components

まだまだ対応していないComponentも多いですが、導入するとぐっとMaterial Design感が出せるのでオススメです!

f:id:YousukeTezuka:20180925180823g:plain

Constraint Layout & Motion Layout

本アプリでは随所に細かなアニメーションを付けています。よりリッチなアニメーションを実現するためにアルファ版ではありますがConstraint Layout 2.0を採用しMotion Layoutを活用しています。

これまでデザイナーから「こういう動きってできますか?」と提案されてもなかなか実現できずに心苦しい場面がしばしばありました。
Motion Layoutによってそれに応えられるようになり、触っていて気持ちいい動きをつけられるようになったように思います。

f:id:YousukeTezuka:20180925181905g:plain

さいごに

一部ではありますがTRAVEL Now Androidアプリで採用した技術を紹介させていただきました!

これからも自動テストやCIの整備、Slicesの対応などまだまだやらなければいけないこと、やっていきたいことが山積みです。
BANKではそんな課題をひとつひとつ一緒に超えていける仲間を募集しています。
少しでも興味を持っていただけましたら、ぜひお気軽にオフィスに遊びに来てみてください!

bank.co.jp