Go College
by
Ogata Katsuya
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
CyberAgentインターン Go Collegeで学んだこと G05 緒方 克哉
Slide 2
Slide 2 text
自己紹介 名前 : 緒方 克哉(おがた かつや) 出身 : 宮崎県小林市 所属 : 大阪大学 基礎工学部 情報科学学科 B3 趣味 : 登山 旅行 サウナ Go College参加前 : ・Go一度も触ったことない ・Go Collegeについていけるか心配。。 ・でもサーバーサイドを静的型付け言語で書いて みたいなぁ。。。 登山 地元小林市 ブルネイのビーチ
Slide 3
Slide 3 text
Appendix 1. 最終課題で取り組んだこと 1. クリーンアーキテクチャの導入 2. 各層のユニットテストの実装/自動テストの導入 3. Redisを用いたパフォーマンスチューニング 4. DataDogを用いたログ/メトリクスの可視化 2. Go Collegeを通した成長ポイント 3. 今後に向けての意気込み
Slide 4
Slide 4 text
Golangでの具体的な実装 クリーンアーキテクチャの考え方 をGolangに落とし込んで実装する ことで、レイヤードアーキテクチ ャの目的や考え方を深く理解する ことができました。 保守性の向上 各層が独立しているため、特定の 機能の変更やバグ修正が他の部分 に影響を与えにくくなりました。 これにより、保守の効率が大幅に 改善。開発の安定性も向上しまし た。 クリーンアーキテクチャの利 点 クリーンアーキテクチャにより、 コードの注意点が分かりやすくな り、開発者間での理解がスムーズ に。階層構造により、変更が特定 の層に限定されるため、柔軟に対 応可能です。 1.1 クリーンアーキテクチャの導入 クリーンアーキテクチャの導入により、開発の柔軟性と保守性が向上しました。
Slide 5
Slide 5 text
1.1 クリーンアーキテクチャの導入 http周りの処理 Request, Responseの処理 処理の流れ/ビジネスロジック アプリケーション内のデータ構造 ロジック Controller Usecase Domain 外部とのやり取り Infrustructure
Slide 6
Slide 6 text
01 各層のテスト実装 クリーンアーキテクチャの各層 に対して、単体及び統合テスト を徹底的に実装しました。これ はバグの早期発見と迅速な修正 を可能にし、コードの信頼性向 上に貢献しています。 03 02 自動化による効率向上 Github Actionsを用いてテストを 自動化し、手動での実行を不要 にしました。これにより開発者 の負担を軽減し、リソースを新 機能の開発に集中できる環境を 用意しました。 1.2 テストの導入 テストの導入はコードの信頼性向上と開発効率の改善を可能にしました。
Slide 7
Slide 7 text
1.2 テストの導入 抽選ロジックのテスト カバレッジ
Slide 8
Slide 8 text
1.2 テストの導入 抽選ロジックのテスト ・10万回ガチャの抽選を実行 ・試行回数×排出確率を計算 ・各アイテムの期待する排出数を算出 ・期待している排出数と、実際の排出 数が設定している誤差の範囲内であっ たら成功 ・確率誤差は0.1%誤差である、100と して設定 MySQLを使用したテスト実行 ・インフラ層のロジックのテストには SQLiteや、モックを用いずに、テスト 用のDBを用意して実施 ・GitHub Actions上でも、都度MySQLを 立ち上げてテストを実行する ・これにより、より本番の環境に近い 状態でのテストを実現
Slide 9
Slide 9 text
DBの負荷軽減 DBとAPIサーバーだと、後者の方が スケールしやすいため、DBにはでき るだけ負荷をかけずに、パフォーマ ンスを上げる。 ユーザーの増加 今後、サービスが成長するにつれて 、最も増えるであろう要素はユーザ ーなので、それを見越して、ボトル ネックになるであろう部分をチュー ニングしていく。 1.3 パフォーマンスチューニング Redisでのデータキャッシュにより アプリケーションのパフォーマンスを改善しました。
Slide 10
Slide 10 text
1.3 パフォーマンスチューニング パフォーマンステストの実施方法
Slide 11
Slide 11 text
1.3 パフォーマンスチューニング 認証部分をキャッシュ ・検証時の状態 ・12,000ユーザー ・cacheなし: 720 msec ・cacheあり: 200 msec
Slide 12
Slide 12 text
1.3 パフォーマンスチューニング マスタデータをキャッシュ ・検証時の状態 ・20,000ユーザー ・220アイテム ・DBとのやり取り ・cacheなし: 1,660 msec ・cacheあり: 1,170 msec
Slide 13
Slide 13 text
01 ログの構造化 zapを使用することで、ログの出 力が構造化され、解析が容易に なります。この構造化により、 特定の情報に迅速にアクセス可 能になり、効率化が図れます。 03 02 可視化の効果 Dataogを用いてログやメトリク スの可視化を実現しました。可 視化により、システムの状態を 一目で確認できるため、問題発 生時の対応が迅速化されます。 1.4 構造化ログの出力と可視化 zapでのログ出力とDataDogでの可視化により、迅速かつ正確な問題解決を可能に。
Slide 14
Slide 14 text
1.4 構造化ログの出力と可視化 メトリクス ログ
Slide 15
Slide 15 text
03 テストをきちんと書く・利用する アーキテクチャに基づいて、各層の責務をきちんと検証することのできるテストコードを書けるようになるこ と。また、テストを最大限活用できる仕組みを整備すること。 02 パフォーマンスチューニング 個人開発ではあまり意識することのない、パフォーマンスを上げる工夫について理解して実践できるようにな ること。特にサービスが大きくなった時のことを考えて設計を行えること。 01 コード品質を上げる 単に、動けば良いというスタンスではなく、変更容易性や、保守性を兼ね備えた品質の高いコードを記述でき るようになること。 2. Go Collegeを通した成長ポイント 設定していた目標
Slide 16
Slide 16 text
・アーキテクチャってなに? ・Goのinterfaceっていつ使うの? ・動けば良いだろう コード品質の向上 ・pprofやk6等のツールを用いてAPIの ボトルネックを見つけることができる ・DataDog等の可視化ツールを用いて 、メトリクスの改善をできる ・Cacheのメリデメを考慮した上で、 適切なCache戦略を考えることができ る 2. Go Collegeを通した成長ポイント パフォーマンスチューニング テスト ・アーキテクチャの目的を理解して、 実装に落とし込める ・各層のinterfaceを実装してDIできるよ うにする ・依存する方向を意識しながら実装 ・各層の責務を意識しながら実装 ・時間がないからテストは書かない ・テスト書いてもあまり効果がないか らいらない ・とりあえず、なんとなくテストを書 いておく ・各層の責務をきちんと検証できるテ ストを書くことができる ・テストがあるおかげでリファクタリ ングした際のエラー改善にかかる時間 を軽減することができる ・実行時間は気にせずに、動けば良い ・DBから逐次取ってきて表示 ・パフォーマンスチューニングって聞 いたことはあるけどなにすればいいか わからない
Slide 17
Slide 17 text
01 アーキテクチャの利用 03 02 今後に向けての意気込み 個人で開発しているものや、イン ターン先でもアーキテクチャの考 え方を導入してみる middlewareの利用 middlewareを意識して、ログを出 力したり、エラーログを追いやす い工夫をしてみる 03 03 パフォーマンス改善 普段からパフォーマンスを意識し て、コードを書いたり、キャッシ ュを活用する 03 04 テストの充実 開発効率を上げるために、テスト を充実させていきたい