UP.tech.blog

UP Parters GroupのSOT consulting IT事業部のTechブログです

AWS Summit Tokyo 2023に行ってきました

IT事業部でリードエンジニアをしております、大坪と申します。

開発チームは先日、業務で使用しているAWSの最新情報を取得すること・AWSをさらに効果的に活用するための新しい視点を得ることを目的に、AWS Summit Tokyo 2023に行ってきました。

せっかく行ってきたので今回はその参加レポートを簡単に書きたいと思います。

AWS Summit のオフライン開催も久しぶりということでしたが、私自身もオフラインのこうした大規模イベントへの参加は久しぶりだったのでかなり楽しみにしてました。

結果、有意義な時間を過ごせて参加してとてもよかったなという感想です!

セッション

参加した開発チームのメンバー各自の興味に合わせたセッションを選んで参加しました。 (たまたまなのか忖度があったのかはわかりませんが)ほとんどそれぞれが別々のセッションに参加したので、幅広い情報収集がチームとして行えました。この辺は個人ではなくチームで参加するメリットですね。

すべてのセッションがとても興味深かったのですが、個人的に印象に残っているのは、

AWSでゼロトラストを実現するためのアプローチ

ゼロトラストについては、リードエンジニアというよりもIT事業部のメンバーとしての視点で聞いてました。 AWSを使ってのセキュリティについては社内インフラを任される立場として、非常に興味深かったです。

社内インフラにAWSを活用する事例は他にもいくつか聞くことができました。 AWSを主に開発したアプリケーションのインフラとして考えていたので、その視点を広げる機会になりましたね。

AWS DeepRacer ワークショップ

自分が組んだプログラムでレーシングカーを動かせる、という体験はシンプルに面白かったです。 今回はさすがに実機にプログラムをインストールして走らせてみる、というところまではできませんでしたが機会を見つけてやってみたいなぁと思いました。

ABEMA の大規模・高画質ライブ配信を支える AWS クラウド動画配信システム

サッカーW杯、私はずっと見てましたのでインフラどうなってたんだろうという興味から参加しました。 W杯見てた人やっぱ多かったんでしょうね、セッションに参加してるひとがとても多くて立ち見でした。 あれだけの規模の配信を大きなトラブルなく終わらせたっていうのは本当にすごいです。

会社に戻ってから、それぞれのセッションに参加した時にとったメモを結合しました。 全部結合するとかなりの量になりましたので、やっぱりそれだけどのセッションも興味深い・勉強になる話だったということなんだなと。

セッション以外だと、企業ブースでの情報収集もできました。 こちらも知らなかったサービスを知れたり、今使ってる・使おうか検討してるサービスの開発者・担当者に直接話を聞ける機会を持てて非常によかったです。

まとめ

新しい情報をいろいろゲットできましたし、久しぶりの大規模なオフラインイベントに参加できて単純に楽しかったです。 あと新しい技術やサービスの話を聞くととても刺激になりました。 帰りの道中、みんなで「あのサービス使えばxxできるのでは?」「あれはどう?」みたいな話で盛り上がりました。

Summitへの参加はチーム全体のモチベーションアップにもなったし、今後もこういった勉強会などあれば積極的に参加してきたいと思ってます。

railsでのAuroraのフェイルオーバーへの対応

UP Parters GroupのIT事業部 開発チームでリードエンジニアをしております、大坪です。

最近はインフラにAWSを採用することがかなり多くなってきてます。 そんな中、データベースとして元々PostgreSQLを採用することが多かったのですが、Auroraを選択することも増えてきました。 データベースの堅牢性とスケーラビリティ、パフォーマンスの向上を期待できるというのがざっくりしたAuroraを選択する理由です。

しかし一方でrailsとAuroraのフェイルオーバーへの対応が課題となりました。

そこで、我々がどのようにこの課題へ対応しているかをご紹介します。

RailsとAuroraの相性

まず、RailsとAuroraは相性抜群!とは現時点では言えないかなと思います。 基本的には、RailsとAuroraはうまく連携できますが、Auroraのフェイルオーバー時にRailsのコネクションプールが問題を引き起こすことがあります。

Auroraのフェイルオーバーとは

Auroraのフェイルオーバーとは、プライマリインスタンスがダウンした際に、自動的にリードレプリカをプライマリインスタンスに昇格させる機能のことです。 これにより、ダウンタイムを最小限に抑えることができます。

Railsのコネクションプールとは

Railsのコネクションプールとは、データベースへの接続を管理する仕組みのことです。 しかし、Auroraのフェイルオーバーが発生した場合、コネクションプールに接続情報が残ったままになり、アプリケーションが正常に動作しなくなることがあります。

この問題を解決するため、

dev.classmethod.jp

を参考にさせていただきました。

class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter
  def active?
    if super
      is_read_only = ActiveRecord::Base.connection
                                       .execute("SHOW transaction_read_only")
                                       &.first
                                       &.fetch("transaction_read_only")
                                       &.upcase == "ON"
      if is_read_only
        ActiveRecord::Base.clear_all_connections!
        false
      else
        true
      end
    end
  rescue Exception => e
    false
  end
end

ここでは、ActiveRecord::ConnectionAdapters::PostgreSQLAdapter を拡張して、接続するデータベースが読み取り専用になっている場合は一度接続を破棄して、再度接続しなおしています。 つまり、フェイルオーバーが発生し、データベースへの接続が切れた場合、コネクションプールを破棄し、新しい接続を確立することで問題を解決しています。

まとめ

色々書いてきましたが、実はこの問題についてAurora導入を決めた当初、恥ずかしながら私は全く知らず、チームのメンバーから「こういう問題があるっぽいよ」と教えていただいたことで初めて知りました。

教えていただいた後、フェイルオーバーやコネクションプールについて改めて調べてみて色々と勉強になりました。

まだまだ知らないことがいっぱいあるなぁ。。。 頑張って勉強します。

どういうふうに開発を進めているか、という話

こんにちは。

UP Parters GroupのIT事業部 開発チームでリードエンジニアをしております、大坪です。

私たちの開発チームでは、スクラムのエッセンスを取り入れて、よりよいチームを実現しようと取り組んでいます。

デイリースタンドアップ、リファインメント、そしてレトロスペクティブといったスクラムの3つの要素を活用し、チーム内のコミュニケーションを改善してきました。 簡単にどういう導入の仕方をしているのか、ご紹介します。

デイリースタンドアップ

デイリースタンドアップを取り入れたおかげで、私たちのチーム内のコミュニケーションが大幅に向上したと感じています。 何か困ったことがあったときに相談するって地味にパワーがいることだなぁと個人的には思ってますが、そういう場が毎日スケジュールとして用意されることで意見交換のハードルが少しは下がったのではないかと感じています。

今の所この取り込みは、チーム全体のパフォーマンスを向上させているように感じています。

ちなみにデイリースタンドアップは、開発チームだけでなく、IT事業部の他のチームにも広がっているようで、組織全体のコミュニケーション改善にも多少なりとも寄与している模様です。

リファインメント

リファインメントでは、チームの少人数制を活かして、誰でも対応できるようなチケットの内容について詳細に合意し、共通認識を持つことを目指しています。 我々開発チームはフロントエンドチーム、バックエンドチームに分かれるような専業制ではない(というかできないというのが正直なところです)ので、できるだけ全員がどのチケットをとっても対応できるようにしておきたいと思っています。

そのため、なるべくリファインメントでは全員でチケットの詳細を詰めることにしています。

このやり方で今の所、チーム内でのタスクの進め方がスムーズになり、効率的な開発ができるようになったと感じています。

レトロスペクティブ

レトロスペクティブでは、チームの運用方法や体制など、さまざまな改善点を定期的に話し合う場を設けています。 元々はスクラム開発をきちんとやろうとしていましたが、レトロスペクティブの場で色々話し合った結果今のこの形に辿り着きました。 きちんと振り返ってその結果を反映させることができてると思っていますし、改善を続けることで、プロジェクトの進行にも好影響をもたらしていると思っています。

まとめ

私たちの開発チームは、スクラムのエッセンスを取り入れた開発業務の進め方がチーム内のコミュニケーションを向上させ、効率的な開発を実現していると感じています。

チームの成長や組織全体の改善に寄与するこの方法は、他の開発チームやIT事業部にも広がりつつあって、今の所事業部全体に良い影響があったかなぁと個人的にはおもっています。

今後もよりよいチームになるように改善を続けていきます!