CO-NECTテックブログ

CO-NECT株式会社開発部門のブログです。テック関連の情報を発信していきます。

CO-NECT株式会社でチャレンジしていること！

CO-NECT株式会社の木村です。

約10年程勤めた楽天を退職して2020年1月からCO-NECT株式会社のエンジニアとして働いて来て4ヶ月経ちました！

自分の感覚では1年以上働いている感じがします（あとなぜか古参感も出してるみたいです）

f:id:co-nect-tech:20200507104725p:plain

CO-NECT株式会社でチャレンジしていること

入社当初からチャレンジしている事の一つとして

今後、急激に利用アカウント数と大企業クライアントが増えることを想定した

システムのパフォーマンス改善を実施しています。

パフォーマンスが与える影響について

なぜパフォーマンス改善対応が必要かと言いますと、

パフォーマンスがサービスの使いやすさに影響を与える。

これは当たり前のことですが。

 

パフォーマンスが最終的にサービスが成功するか失敗するかを決める大きな要因の一つになっているからです。

パフォーマンスを制するものはサービス成功を制するといっても過言ではないでしょう！

(NO Performance NO Success Of Service)

と私は思っています。

パフォーマンスがオンライン ベンチャーの成功に及ぼす影響は非常に大きくなっています。

パフォーマンスの低いサイトと比較してパフォーマンスの高いサイトがどのようにユーザーの注意を引き、ユーザーを引きつけておくことができるかを示すいくつかの事例があります。

　・Pinterest では、ユーザーが体感している待ち時間を 40% 削減した結果、検索エンジンのトラフィックとサインアップ数が 15% 増加しました。

　・COOK では平均ページ読み込み時間を 850 ミリ秒短縮したところ、コンバージョン数が 7% 増加し、直帰率が 7% 減少し、セッション当たりの閲覧ページ数が 10% 増加しました。

パフォーマンスが悪かったことが原因で、ビジネス目標に悪い影響が及んだいくつかの事例があります。

　・自社サイトの読み込みにかかる時間が 1 秒増えるごとに BBC はユーザーが 10% ずつ減少することを発見しました。

　・ページの読み込みにかかる時間が 3 秒を超えると、DoubleClick by Google は 53% のユーザーがモバイルサイトの訪問をあきらめることを発見しました。

developers.google.com

DBのパフォーマンスチューニング

今回はパフォーマンス対応の中でもDBチューニングによるパフォーマンス対応を紹介したいと思います。

知ってる人には当たり前！と思う内容で恐縮ですが、

DBチューニングは知っていれば簡単に対応ができて、すぐ有効になるパフォーマンス対応の一つです。

DBパフォーマンスチューニングの進め方

弊社では下記のステップでDBパフォーマンスを対応しています。 

 

Step1. 【各ログの出力】SQLクエリの実行ログやプロファイリングによるログを出力

Step2.【調査】フロントエンド・ネットワーク・API・DBなどの切り分けを実施し、

　　　　　　　  DBの場合は下記の”DBのチェックポイント”で原因を調査

Step3.【改善】原因にあわせた対応を実施（”改善方法”を確認）

Step4. 【リリース】問題がなくなったらリリース

DBのチェックポイント

DBのパフォーマンスへ影響をあたえるのは以下の項目になります。

No

項目

理由

システムへの影響

1

大量のSQLクエリを発行しているか

  • フロント側の実装も問題になることがありますが、フロント側では全てのSQLクエリ実行が完了するまで待つことになります。
    そのため一つ一つのSQLクエリが早い場合でも大量のSQLクエリを実行してしまう処理だとパフォーマンスが遅くなってしまいます。
  • レスポンス遅延
  • CPU高負荷

2

スロークエリが発生していないか

  • スロークエリは応答に時間がかかるだけでなくDBのCPU高負荷の原因にもなります。
  • レスポンス遅延
  • CPU高負荷

3

参照系はリードレプリカを利用しているか
（書き込み処理・読み込み処理を管理する）

  • 読み込み処理を分散することでDBの負荷を軽減します。

  • マスターに負荷をかけずに処理したいときに有効になります。
  • マスター（更新処理）が遅延する
  • レスポンス遅延
  • CPU高負荷

4

適切なトランザクションが設定されているか

  • 特に更新系で大量のSQLクエリを実行するときに１レコード毎にDBとのトランザクション管理している場合は処理が遅くなります。
  • マスター（更新処理）が遅延する
  • レスポンス遅延
  • CPU高負荷

改善方法

1. 大量のSQLクエリを発行している場合

  • データを更新する処理の場合（更新系）

    • bulk updateで纏めて更新処理を実行する。

    • MySQLではLOAD DATA INFILEを利用する。

  • データを取得する処理の場合（参照系）

    • テーブルを結合することで必要な情報を一度のSQLクエリで取得するようにする。

    • 参照用のテーブルもしくはKVSから取得するようにする。結果として、１回の処理で完了するようにする。

2. スロークエリが発生している場合

  • インデックスの追加

    • WHERE文で利用するカラムにはインデックスを追加する。

    • テーブル結合で利用するカラムにはインデックスを追加する。

  • 複合インデックスの追加

    • WHERE文で複数の条件が設定されている場合は複合インデックスを追加する。

  • 型を統一

    • テーブルを結合するときにカラムの型が同じでないとインデックスが効かないので
      結合するカラムは同じ型を設定する。

  • サブクエリを利用しない

    • サブクエリの場合はインデックスが効かないので、サブクエリを利用しない。

3. 参照系の処理について

  • （参照系）読み込み処理はリードレプリカを利用する。

4. トランザクションの処理について

  • 更新系で大量のSQLクエリを実行するときは１レコード毎にDBとのトランザクションを設定しないで、全体の開始と終了のみに設定する。

 

次回も取り組んでいる事や開発したプロダクトの紹介などを書いていきたいと思います。

最後に、CO-NECT株式会社に入ってよかったこと

  • なんといってもメンバーが最高です！

  • サービスが魅力的です！

  • やりがいが沢山あります！

人生色々チャレンジしたい！とい思ってたところ

前職時代の飲み友達との縁でCO-NECT株式会社に入りましたが、毎日楽しく日々をおくっております。

正直、もっと早くチャレンジしても良かったと思っています。

 

そんな当社では、サービスを一緒に作ってくれる仲間も募集中です。興味のある方はお気軽にお問い合わせください！

conct.co.jp