ガッチャモール内で過去に発生したバグ・不具合などをまとめてみました。
過去に発生したものなので、現在のバージョンでは解決済み・発生しないものも含まれていますので参考にする際にはご注意下さい。
今回は、３つのケースを紹介します。
「バグ」とは、その機能の不備を生むプログラム内の不具合を指す言葉です。
また、不具合とは、プログラムが仕様書通りに動かないことです。
つまり、思った通りに動かないプログラムを見て「バグがある」と表現します。
引用元：https://tech-camp.in/note/technology/94046/
ソフトウェア構成図
1.Javascript「;」による閉じ忘れ
関数等、処理の最後の「;」による閉じ忘れが存在。
「 }) 」のような")"にセミコロン";"を付けないとブラウザによってはSyntaxErrorの原因となる
if(navigator.geolocation){
navigator.geolocation.getCurrentPosition( successFunc , errorFunc , optionObj ) ;
} else {
var apiUrl = '/api/foge/foge';
var pathname = location.pathname;
$.ajax( {
type : 'GET',
url : apiUrl,
beforeSend :
function( xhr ){
xhr.setRequestHeader("pathname", pathname);
}
} );
}
Javascriptに関しては、他にconstが利用できないブラウザ（IE10など）でエラーが発生したものもありました。
const EXPIRING_MINUITES = 5;
var EXPIRING_MINUITES = 5;
2．重複インサートに伴うロック場所の見直し
重複リクエストに伴う重複インサートの対策。
対象テーブルを行ロックしていなかった為、重複インサートにより重複エラーが多発した。
※unique keyを設定しているのでDB上のデータ不整合はなし
対応内容：
トークンに一致する対象テーブルを行ロックすることによって現象を防ぐ。
以下に、SampleRepositoryクラスのメソッドを抜粋。
/**
* <p>トークンによるSampleTableの取得（ロック）</p>
*
* OPTIMISTIC : 楽観的
* PESSIMISTIC : 悲観的
* PESSIMISTIC_READ : 共有ロック. lock in share mode
* PESSIMISTIC_WRITE : 排他ロック. for update
*
* @param token
* @return
*/
@Transactional
@Lock(value = LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT FROM sample_table WHERE registorToken = ?1")
public SampleTable findByRegistorTokenAndLock(final String token);
3.フロントサーバーログの肥大化によるディスクリソース逼迫
Line配信を開始したことで、新規ユーザーの大量流入でログが肥大化しEC2内のディスクリソースが逼迫した。
対応内容については、インフラチームと検討・調整し対応を実施。
また、不要なログ出力や出力内容を改めてアプリチームと精査した。
対応内容：
・ログローテートとファイル圧縮
・日次でS3へログをバックアップ
・S3 Glacier Instant Retrieval導入によるコスト削減
・ ログローテートとファイル圧縮
EC2内の当日ログは圧縮せず生ログのままとし、後はログローテート時にログファイルの圧縮する仕組みを導入した。
※EC2内のログの保存期間は１週間とした
・ 日次でS3へログをバックアップ
上記にて、１週間経過したログファイルをS3へバックアップする仕組みを導入した。
S3にバックアップ後、S3にライフサイクルを設定することで、不要となったファイルを自動削除出来るようになった。
ライフサイクルに設定する期間については、分析・調査・参照することがなくなる期間を考慮。
・ S3 Glacier Instant Retrieval導入によるコスト削減
上記２つを対応してから数年後、「S3 Glacier Instant Retrieval」というサービスがリリースされ、コスト削減目的で利用する事とした。
180日前のログは通常のS3ストレージに、半年（180日）経過した物は、「S3 Glacier Instant Retrieval」に移行するように設定することでコストを削減が出来た。（ストレージコストを最大 68% 節約）
詳細についてはこちら（S3 Glacier Instant Retrieval）