サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
tsuyoshi-nakamura.hatenablog.com
はじめに Goで色々とアプリケーションを書いていてストレージ(主にRDB)との結合部分のテストを書く事があると思います だいたいは実際のストレージにアクセスするテストを実行して、テストをするかと思います 最近、自分はこのストレージ部分とのテストをより良くするにはどうすべきかと考える時があります そこでdatabaseの結合部分のテスト周りで最近改善してみた事をまとめたいと思います 今までどうしてたか localの場合 まず、実際のテスト用のHOST,DB,USER,PASSWORDをconfigなり、環境変数化しておいて、起動時に切り替えれるようにしておく unit test用のDBを用意しておく テーブルスキーマのmigrationを流しておく test用のconfigで起動してgo testを流す。 実際にテスト用のDBに対して、select,update,deleteのテストを行う
はじめに ようやく、ユーザ向けにリリースが終わった様子なのでここで一つまとめておこうと思います。 どこの部分をリプレイスしたのか? この部分です PC SP おことわり フロントのHTMLの組み込みのところは別のチームのエンジニアにお願いしていて、自分はバックエンド側のみになります 今までの課題感や要件的なもの 今まではmysqlのLike検索だった。サービスが成長して、Like検索だとSlow Queryが多く出はじめたでこれを対応したい mysqlのチューニングやプラグインで対応していく方向性でも出来ないことはないと思うけど、手数がいるし、スケール難易度が上がるのでその方向性はやめたい feed検索サービスとして、既存のシステムからなるべく切り離して独立性を保って運用していきたい マイクロサービス化の流れですね〜 せっかく、新しくするのなら、サジェストとかは入れたいな〜 対応チーム 自
はじめに developers.cyberagent.co.jp 最近ウチはAuroraに切り替えをしました。🎉🎉🎉 当然良かった点はいくつもありますが、一つにリーダーエンドポイントが気軽に増やせることがあります なので一つAurora Readerを作成してAnalytics用途として活用しています。このコトを契機に分析用の仕組みを色々と改善できるなーと感じていて Aurora切り替えが無事に完了してRedash導入後、1ヶ月経過したので少しまとめて見ようと思います Redashに移行する前の分析 バッチで必要なデータを取得・加工してElasticSearchに入れる Kibanaからグラフ化してダッシュボード化して見ていた ここでの課題感 分析するデータが増えた場合、バッチ修正して、既存Indexも作り直してってとても面倒だった😰 定期バッチで取り込んでいたので多少なりともタイ
はじめ もっともっとキャッシュをうまく活用することでよりスケーラブルに、よりレスポンシブにしたいなーと考えていて幾つかのパターンを考えたのでまとめておこうと思う キャッシュといえども広義になってしまうけどここではhtml全体をキャッシュさせてレスポンスさせるキャッシュを指して書きます 設計する上のでポイント ユーザ毎の情報をいかにキャッシュから返すか staticなデータはまぁ良いとしてユーザ毎のデータのキャッシュはしくると情報漏えいとなってしまい大事故になるので慎重に!! キャッシュをさせたくないデータ(ex:ECサイトだったら在庫数とか)をどう扱うか 考えたパターン varnishを活用した場合 説明 varnishはpostやget、urlによってキャッシュするしないという設定が柔軟で😃 varnishの設定によりキャッシュさせるページ=データを設定する 図の流れのように順番に上か
はじめに そろそろAPIをちゃんと切り出して運用したほうが良いよなーとか、ネイティブアプリやる時に必ず必須だしなぁーとか思ってた。 でせっかくならGolangでやった場合どんな感じになるかなと思いながらかる~く調べていた。 Golang自体の書き方云々はまぁ良いとして、実際のAPIを公開して運用するときにさてどんな構成が一番良いんだろうとかちょっと疑問に思った。 んで何通りかあって、どれが一番ベストパフォーマンスが出るんだろうなーと疑問に思ったのでそのあたりのbenchmarkとったのでまとめる 検証環境 NginxでまずはHTTP通信を受ける GoのフロントにNginxを置くのはキャッシュ、Logging等々、インターネットからのアクセスを受け付ける役割としてはNginxを使ったほうが最終的に良いだとうと最終的になりそうだったので入れた その後、Golangに投げて、Golangではmy
静的コンテンツ(CSS,Image,JS)をCDNから配信するとサイトの表示スピードが格段にあがるよってゆう話はかなり今更感ですが、それは前提として1日何回もデプロイを繰り返すサービスを考慮するとCDNのキャッシュとライフサイクルにどううまく付き合うかが結構課題になってきたりします。 そんな課題にどうやって対処したかをまとめておこうと思います 全体説明 静的コンテンツ(CSS,Image,JS)はすべてS3に格納 S3を通常のバケットとして設定 以前は直接S3のURLを参照してコンテンツを配信していたが、パフォーマンス的にNGなので今はCloudFrontから配信している 静的コンテンツ以外はELBにアプリケーションサーバ群が存在、その先にDB等がある。storage系は今回省略 抱えていた・想定された課題 CDN(CloudFront)からコンテンツを配信した場合、キャッシュの更新が全世
このページを最初にブックマークしてみませんか?
『nakamura244 blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く