RubyKaigi 2019に弊社から2人が業務扱いで参加してきました
4/18から4/20にかけて福岡国際会議場で開催されたRubyKaigi 2019に、弊社からは私 id:yu_suke1994 と id:HolyGrail の2名が業務扱いとして参加してきました。
興味深いトーク
今回のRubyKaigiでは、Ruby 3に向けての進捗報告があったり、Kaigi終了後ではありますがSVNからgitへの移行が完了したりと、色々と今後のRubyが楽しくなりそうなトピックがcore teamから共有されました。
ruby trunk のマスターが git になってた。めでたい。 @hsbt と @k0kubun の頑張りのお陰です。ありがとうございます。
— みょうが (@mrkn) 2019年4月22日
また毎度おなじみ "Ruby Committers vs the World" では、スクリーンに写されたhackmdの画面に皆さんが思い思いのアイデアを書いていく様が見ていてとても面白かったです。
他にも聞きたい発表ばかりでしたが、肉体は一つしかないのでした。動画の公開を首を長くして待つことにします。
福岡はいいところ
今回のRubyKaigiは福岡で行われましたが、福岡は美味しいグルメがたくさんあることで有名です。開催までに、様々なブログで「ここは行っておけ」スポットの紹介がされていたのは記憶に新しいかと思います。
弊社でも、福岡出身の社員からオススメのご飯情報を事前に共有してもらい、滞在中は毎晩舌鼓を打って過ごすことができました。
胃腸を壊してフィニッシュという結果になったのでしばらく胃腸に優しい生活を送ります pic.twitter.com/7xo60uWVew
— HolyGrail / 蜘蛛糸まな🕸️@新人VTuber (@HolyGrail) 2019年4月21日
Conference week in Fukuoka
ところで、実はRubyKaigi 2019の前にはCloudNative Days Fukuoka 2019も開催されていました。 id:yu_suke1994 はこのイベントにも業務扱いとして、弊社からの支援を受け参加してきました。
弊社では、マネージドKubernetes基盤の上でRailsアプリケーションを開発・運用しています。なので、Cloud Native界隈にも積極的に参加していきたいという想いがあります。
来年は松本開催
そしてRubyKaigi最終日には、次回は長野県松本市で開催されることが発表されました。もちろん私達はもう参加する意気込み十分な状態です。
来年の松本でまたお会いしましょう！
WE ARE HIRING!
私達は一緒にRubyKaigiに参加したい、というメンバーを募集しています！！
Japan Container Days v18.12 参加レポート
12月3日から5日にかけて、Japan Container Days v18.12が開催されました。弊社からは、業務扱いで id:yu_suke1994 と id:fujikawa-y の2名が参加しました。今回はその参加レポートになります。
多くのセッションに参加しましたが、その全てに言及するととんでもなく長い記事になってしまいそうなので、印象深かったセッションに絞って感想を書いていこうと思います。
keynote
keynoteでは、複数の企業におけるKubernetesの役割などについて話されました。
CNCFのChris Aniszczyk氏からは、CNCFの目指す地点、今後のロードマップなどについての話がありました。Serverlessだけではなく、Nodelessへの流れ、KubernetesをIoTやedge computingの世界まで広げたいという野望、kubeletそのものを仮想化するvirtual-kubeletの紹介などがありました。
また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がデファクトスタンダードになっているが差別化は？
- 今後追うべき技術は？
- Knative
- サービスメッシュが来る。Istioがきて成熟期になる
- イベント情報をキャッチアップすることが大事
- CoreOSも追うべきもので、それも含めて運用を楽にするためのもの
- AIのKubeflowでデータパイプラインが必須な部分なのでこれも追う
Cloud Nativeプロダクト1000本ノック
CNCF Landscapeには、CNCFでないプロダクトも含め、600を超えるプロダクトが掲載されています。
このセッションでは、データストア、CI/CDなどのトピックに分けて主要なCNCFプロダクトの紹介が行なわれました。辛うじて名前だけ聞いたことがあったりするものや、初耳なプロダクトも結構あって、こんなの追い切れないだろう……と思いました。だからこそ、コミュニティとして活動し、様々な検証を持ちよって情報を共有し合うことが重要になるのですね。
また、Cloud Native Trail Mapを見るとわかるのですが、コンテナ化、Kubernetesによるオーケストレーションは "Cloud Native" という観点ではまだ入口に過ぎず、そこで満足していてはいけないのだなということも感じされられます。(プロダクトの規模にもよるとは思いますが……)
また、このセッションで知ったのですが、Spinnakerがpipelineをコードで管理できるようになっていたのには驚きました。それまではGUIによるpipeline定義しかできず、.circleci/config.yml のようにコード化できないのはちょっと、なーと思っていたところなので、導入に向けて前向きになれますね。
pipelineの定義については、イベントでデモとして提供されていたshowKs( https://showks.containerdays.jp/ )で実際に使用されているものがGitHubで公開されています。
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
ディスカッション形式で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の直前ということで、僕は個人的にめちゃくちゃ盛り上がっています。
CloudNative、やっていきましょう。
sidekiq-cronアップデートへの道のり
こんにちは。ジョブスケジューラーとしては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 できた……と思っていた
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_OLD と LAST_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つが候補としてありました。
- 正しい書式の時刻をRedisに格納し直す
- 独自定義した書式からは時刻単位の情報が欠落しているので復元が不可能
- Redisの値を手で操作したことがなく、不安
- sidekiq-cronで使用している key-value の組を全部削除する
- これまでの実行情報が全て消えてしまう(が、そもそも正確ではないし……)
- 独自定義を削除し、正しい書式でRedisに格納されるまで待つ
- 時間はかかるが安全
ということで、「独自定義を削除し、正しい書式でRedisに格納されるまで待つ」ことにしました。CronJobのなかには、毎月1回実行されるというものがあります。なので、 Time::DATE_FORMATS[:default] の設定を削除してから1ヶ月待ち、Redisに格納されている last_enqueued_at の書式が全て正しいものになっているかどうかを確認したうえで、sidekiq-cronのアップデートを行いました。
まとめ
という訳で、継続的bundle updateの体制が整いました！流れでRailsのバージョンも5.2.1になりました。
引き続き、やっていきましょう。
-
今考えると、そのようなことをする必要はなかったんじゃないかと思いますが……↩
【開催レポ】BANK engineer night #02 〜狂ったようなことをしよう〜
こんにちは。BANK広報の磯田です。
2018年10月11日に『BANK engineer night #02 〜狂ったようなことをしよう〜』を開催いたしました。BANKではBANK engineer nightを通してBANKのメンバーが、普段どのようにスピリットを持ちながらサービスを開発しているのかを、 多くの人に知ってもらいたい、という想いから今回のイベントを企画いたしました。
現在BANKは、『CASH』と『TRAVEL Now』の2つのサービスの開発・運営を行なっています。 今回のイベントでは、2つのサービスを世に出し、育てていく上で、いかに狂ったように振り切ってきたのかをエンジニア4名がLTでお話しました。
眼の前のアイテムが一瞬でキャッシュに変わる『CASH』
https://cash.jp/
あと払い専門の旅行代理店アプリ『TRAVEL Now』
https://travel.app/
発表プログラム
CEO光本からご挨拶
はじめに、CEO光本からみなさんにご挨拶です。会社紹介と、運営している２つの事業についてお話させていただきました。
『エンジニアがうらやましい。まだ世の中に無いサービスを作り出すことができるから。』という話をしていて、みなさん深く頷かれていました。
魅力品質をアゲて見たことないサービスを認知してもらう
iOSエンジニアの高橋からは、今回初めて開発秘話が話される「TRAVEL Now」のお話でした。
ユーザーの心をつかむ「魅力品質」と絶対に必要な「当たり前品質」の両方を落とさずに、新規事業の開発についてお話しました！ 今までにないサービスを世の中に出すことは、受け入れられるのか怖いけど、だめならブラッシュアップして直せば良いという気持ちで開発に臨んでいたそうです。
スピード狂エンジニアたちの開発速度を保つインフラとは
サーバーサイド兼インフラエンジニアの高橋からは、スピードのお話。
入社してからどんどんメンバーが増えていく中で、数人規模で開発していたときのスピード感を落とさずに開発できる環境を整えたお話でした。 「インフラはあくまで裏方」という言葉が印象的でした！
なぜBANKは名刺でお金をばらまくのか
Androidエンジニアの遠藤より、名刺でお金をバラまいたお話をさせていただきました。
なぜ名刺なのか。おもしろさと有用性の伝え方を開発者目線からお話しました。 遊び心を忘れないバンクのエンジニアらしいアイデアですね。
Knativeで限界突破 〜Push通知をバラ撒くために〜
サーバーサイド（Ruby）エンジニアのうなすけからもバラまきのお話。こちらは「Push通知」をバラまいたようです。
CASHのユーザーに数十万件単位で送ったプッシュ通知についてお話しました。 実際に会場で、デモをして盛り上がりました！
懇親会
バンクの他のメンバーも応援に来ていたので、参加者のみなさまとお話することができました！スペースがいっぱいになるくらいの人に来ていただき、懇親会もとても盛り上がりました。
おわりに
今回のイベントでは、『CASH』と『TRAVEL Now』の開発秘話についてご紹介いたしました。 BANKメンバーがどんなことにこだわり抜いて、狂ったようにサービスを育てているのか伝わるイベントになっていたら幸いです！ BANKでは、サービス改善や新規事業に向けて日々取り組んでいるところですが、実現したいことに対して、まだまだ力が足りていません。そこで、一緒に新しいことをやっていただけるメンバーを探しています。
今後のイベント情報についてはConnpassページについて随時更新予定です！イベント更新情報にご興味がある方は、ぜひメンバー登録をポチっとお願いします！
Google Cloud NEXT'18 in Tokyoで登壇しました
こんにちは。発表では早口になりがちなうなすけ (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でも採択されるような発表ができるよう、日々切磋琢磨していきたいですね。やっていくぞ！！
我々はそんなやっていく気持ちがあるエンジニアを募集しています。興味がありましたら、是非お気軽にご応募ください。
