タグ

ブックマーク / engineer.retty.me (8)

  • マイクロサービス時代のセッション管理 - Retty Tech Blog

    この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、

    マイクロサービス時代のセッション管理 - Retty Tech Blog
  • Rettyのデータ基盤の歴史と統合 - Retty Tech Blog

    書き手:@takegue (分析チーム) Rettyのデータ活用の多くにはBigQueryが現在利用されており、その活用の方法についてこれまでこのブログでもいくつかとりあげさせていただきました。 engineer.retty.me そのほか分析チームの記事一覧 これらの記事はおかげさまで好評いただいております。いつもありがとうございます。 しかしながら、我々が初期からこのようにBigQueryを使い続けてきかというと、実はそうではありません。 事業の成長とともにデータ基盤を変化させてきた経緯があり、今の成果は過去のトライアンドエラーの賜物であり、数多くの苦労を背景にしてできあがっています。 ほんのつい最近まで、Rettyで構築されていたデータ基盤は表立って見える実態よりもかなり複雑なパイプラインで構成されていました(以降で触れますが、4種類のデータパイプラインが共存しているカオスな状態でし

    Rettyのデータ基盤の歴史と統合 - Retty Tech Blog
  • エンジニア評価制度の取り組みを振り返ってみた - Retty Tech Blog

    はじめに Rettyでは2018年から組織的な改善活動を数多く始めており、その一つにエンジニアフィードバック(以下、フィードバックはFBと省略します)制度があります。 記事はRettyエンジニアFB制度への取り組みの紹介を兼ねた、これまでの改善活動の振り返り記事となっています。 (2018, 2019年のアドベントカレンダーの小迫の記事に組織的な改善活動についての紹介がありますので興味がありましたらご参照ください) engineer.retty.me engineer.retty.me エンジニアFBは今なお半年の評価ごとに継続的に改善を繰り返していて、今は4回目の改善サイクルとなる2020年上期のエンジニアFBが終わった頃となります。 対象としたい読者 下記のような項目にピンと来る方に読んでいただけると嬉しいです。 会社のエンジニアが評価に対して不満を抱えており、他社の評価制度の取り

    エンジニア評価制度の取り組みを振り返ってみた - Retty Tech Blog
  • 「1プロダクトをみんなで作る!」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog

    この記事は Retty Advent Calendar 2019 8日目の記事です。 qiita.com はじめに LeSSを選択した背景 LeSS展開のプロセス 1チームスクラム期(4月〜6月) テスト導入期 (7月〜9月) 全社展開期 (10月〜12月) 導入後の状況と今後の課題 おわりに はじめに マネージャーの常松です。 6月に入社して以来、開発プロセスの改善に携わってきました。 今年は大規模スクラム Large-Scale Scrum(LeSS) アジャイルスクラムを大規模に実装する方法が刊行され、アジャイル開発・マネジメントの勉強会でも大規模スクラム(LeSS : Large Scale Scrum、以降LeSSと表記)の名前を聞くことが増えたように感じています。 しかしだけを参考に自分の組織で大規模スクラムを導入していくのはまだまだ難しいのではないでしょうか? スクラム

    「1プロダクトをみんなで作る!」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog
  • Amazon Aurora 移行大全 #1 - Retty Tech Blog

    今年もはじまりました Retty Advent Calendar 2019 ! 初日を担当いたします技術部の西村です。 さて私は 2 回に分けて 『Amazon Aurora 移行大全』 という内容で書いていきます。 ※ Amazon Aurora については Amazon Aurora をご参照ください。 ※ 以降 Aurora と記載 移行対象環境の説明 移行の経緯 事前調査/検証 コスト調査 テーブルスキーマ変更調査 MyISAM から InnoDB への変換 COMPRESSED から DYNAMIC への変換 カスタムエンドポイント調査 性能検証 移行準備 参考資料 2 回にわたる内容は下記を予定してます。 移行対象環境の説明 移行の経緯 事前調査/検証 移行準備 並行運用 メンテナンス作業 移行を終えて 初回は 「移行準備」 まで触れて終わりにします。 ちなみに Aurora

    Amazon Aurora 移行大全 #1 - Retty Tech Blog
  • エンジニア オンボーディングの改善取り組みの紹介 - Retty Tech Blog

    エンジニアリングマネージャーの常松です。 最近のRettyは定期的に新しいメンバーが入ってくる状況にあります。 新メンバーに能力を少しでも早く発揮してもらえるよう、オンボーディングの改善に取り組んでいます。 上記は6/13に開催されたEngineer Onboarding Meetup #1で、VPoEの小迫が登壇した際の資料です。 オンボーディングとは 企業が新たに採用した人材を職場に配置し、組織の一員として定着させ、戦力化させるまでの一連の受け入れプロセス を意味します。 誰に聞いたら良いのかという「人の課題」、前提とするべき知識が揃っていない「情報の課題」、会社・部門からの期待値とずれがある「カルチャーの課題」に対し、全社・部門・個人で行っている具体的な施策を勉強会では紹介しました。 記事では2019年6月に入社した自分が実際に体験したオンボーディングプロセスの紹介と、その後に始め

    エンジニア オンボーディングの改善取り組みの紹介 - Retty Tech Blog
  • カラムナフォーマットのきほん 〜データウェアハウスを支える技術〜 - Retty Tech Blog

    こんにちは、Retty.Inc ソフトウェアエンジニア兼データサイエンティストのchie(@chie8842)です。 好きなたべものは焼肉とみかんです。 現在Rettyでは、次世代分析基盤を構築しています。Rettyでは、サービス拡大に伴いログの急増や分析需要の拡大が見込まれるため、高いスループットとコストパフォーマンスを両立する、スケールするアーキテクチャ設計が求められています。 今回は、こうしたスケールするアーキテクチャ設計の実現のために理解しておくべきDWHのコア技術の一つである、カラムナフォーマットに焦点を当てて紹介します。 はじめに - カラムナフォーマットとは カラムナフォーマットとは、データベースの分析用途に利用されるファイルフォーマットの種類の一つです。大量のデータを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくで

    カラムナフォーマットのきほん 〜データウェアハウスを支える技術〜 - Retty Tech Blog
  • RettyとKotlinの歩み〜アプリからサーバサイドまで - Retty Tech Blog

    RettyAndroidエンジニアとして働いている福井 と サーバサイドエンジニアの石田です。 Googleから「AndroidKotlin正式サポートする」と発表されました! 🎉🎉 そんなKotlinですが、弊社では去年2月頃からプロダクトに導入しています。今回はその歩みと一年以上使ってきた感想をご紹介します。 Androidでの導入事例 最初にKotlinを導入したのはAndroidチームでした。タイミングとしては1.0が正式リリースされる少し前から導入を検討していました。 まずはプロダクトと直接関係ない小さなアプリを書き、これで行ける!と判断したのと正式リリースのタイミングがちょうど重なり導入を決断しました。1 プロダクトに導入する際は、新規ファイルを作成する時にJavaではなくKotlinで書くといったようにファイル単位でじわじわKotlin化していきました。今ではJa

    RettyとKotlinの歩み〜アプリからサーバサイドまで - Retty Tech Blog
  • 1