新着記事

エンジニアの高津です。
今回はこの1ヶ月でどのような業務を行ったのか紹介していきたいと思います。
TORICOにエンジニアとして入社を検討している人に少しでも参考になれば幸いです。

主な業務内容

自分はコーマス開発部で、漫画全巻ドットコムの開発をメインでやっています。

簡単なバグ（UI）の修正と漫画全巻ドットコムのリニューアルの大きく２つに分けられます。

簡単なバグ（UI）の修正

こちらは数時間で終わるような簡単なUIの修正（改修）で入社して3日後にはプルリクエストを出していました。

• アイコン(font-awesome)が正しく表示出来るようにする
• 個人情報同意フォームの改修
• 電話番号記入欄のに数字が4文字入るようにする
  などの業務を行いました。

漫画全巻ドットコムのリニューアル

漫画全巻ドットコムは10年以上続く歴史のあるサービスで最初はPHPで作られていました。
メンテナンス性に問題があったのでDjango+Nuxt.jsにリプレイスしています。
今回自分は電子新着ページ＋電子割引ページをリニューアルしました。（ブログを書いている時点で実装は終わっていますがレビューが終わってないので本番にはまだ反映されていません）
Nuxt(フロントエンド）は先輩方が作ってくれた雛形を軽く修正して利用出来るのでDjnago(バックエンド）の実装がメインでした。
今回はその中でも難しかったポイントをいくつか列挙したいと思います。

キャッシュを効かす

SQLの実行回数（IO）を極力少なくしパフォーマンスをあげる

今回一番苦戦しましたポイントです。
ただ実装するだけであればすぐ終わったのですが、最初の実装ではSQLを12回叩いてしまっていたのでリファクタリングする必要がありました。（俗に言うN+1問題が発生していました）
こちらはやり方を先輩方にご教示頂き、MySQLにだけサポートされているconcat関数をraw_queryで使い１回で取得することに成功しました。
実際には以下のようなSQLに落ち着きました。

select GROUP_CONCAT(sample_id) AS ids, group_type from
dtb_sample WHERE aggregate_type=
'%s' AND product_type = 2
group by group_type ORDER BY sort_key;

テスト

TORICOの開発ではただ動くものを作るだけでなくその後の保守運用のことも考慮して単体テスト、統合テストも書くように徹底されています。
特にDB設計が少々複雑なこともありテストデータを作るところはかなり苦戦しました。

具体的には以下のようなことをテストしました。

• 各URLにgetして正しい値やstatusが返ってくるか
• 各メソッドのすべての条件分岐において正しく動作するかどうか

これらのテストを書くことでテストのしずらいメソッドが見つかり、それをリファクタリングすることで保守性の高いコードに改善出来ます。

また、仕様が分からない人がみても理解できるようにWhy「なぜこの処理を書くのか？」を極力書くように意識しました。

まとめ

如何でしたでしょうか？

今現在23卒のエントリーを受け付けています。
少しでも興味を持ってくれた人は是非応募して頂けると幸いです。

RDS で、大量のIO を伴う処理を行うと、処理途中で性能が大きく劣化することがあります。
不要になった大量の過去データをバッチで削除する時によく発生します。

これは、ストレージへの IO を規定量より高い頻度で行った時に減少するクレジットがあり、それが 0 になった時、パフォーマンスに制限がかかってしまうためです。

制限のかかった状態では通常通りのサービス運用はできなくなってしまうため、過去データ削除などの高負荷のバッチは、RDSのモニタリングページを見ながら注意深く実施する必要があります。

今回は、パフォーマンス低下を避けるために確認すべき RDS クレジットのメトリクスについて書きます。

各メトリクスの詳細は、AWS の公式ドキュメントに詳細な解説があります。 

高負荷な処理を行う際に確認すべきメトリクス

EBS Byte Balance

AWS のドキュメントによると、「RDS データベースのバーストバケットに残っているスループットクレジットの割合。」とのこと。データ転送量で減少していくのでしょうか。重い SQL を実行することで減ることがあります。

0になるとパフォーマンスが大幅に劣化します。

クレジットを消費するような SQL を実行しなければ、自動的に回復します。

EBS IO Balance

AWSドキュメントによると「RDS データベースのバーストバケットに残っている I/O クレジットの割合。」とのこと。広範囲の DELETE 文など、 IO が多く発生する SQLを実行するとどんどん減っていき、0になるとパフォーマンスが大幅に劣化します。クレジットを消費するような SQL を実行しなければ、自動的に回復します。

Burst Balance

AWSドキュメントによると「汎用 SSD (gp2) のバーストバケット I/O クレジットの利用可能パーセント。」プロビジョンド IOPS の RDSには項目がありません。GP2 ストレージの場合に、広範囲の DELETE 文など、 IO が多く発生する(IOバーストがされる) SQLを実行すると減っていきます。

CPU クレジット残高

T系インスタンスの場合にあります。CPUを多く使う(CPUバーストがされる)処理を行うと減っていき、0になるとパフォーマンスが大幅に劣化します。T系のEC2とお使いであれば、おなじみの項目ですね。

バイナリログのディスク使用状況とリードレプリカのレプリケーション遅延

リードレプリカをマスターより低い性能で運用している場合、マスターで行った処理を同じ速度で処理することができず、レプリケーション遅延が発生することがあります。

この時、リードレプリカが処理できないバイナリログはマスターの RDS に蓄積されるため、バイナリログのサイズが溜まっていき、リードレプリカの遅延もどんどん大きくなります。

解消させるにはマスターの処理のペースをリードレプリカに合わせて減らすしかありません。

状況に気づかずに大きな遅延とバイナリログができてしまった場合、遅いリードレプリカの処理を待つより、一度リードレプリカを削除し、新たに作り直したほうが時間短縮になる場合があります。

まとめ: 高負荷な SQL を発行する時に気をつけること

クレジット消費で一番やりがちなのは DELETE 文で多くのレコードを消そうとした場合です。また、その DELETE で変更されたストレージを最適化させるための OPTIMIZE TABLE でも多くのクレジットが消費されることがあります。

DELETE を行う場合、量にもよりますが、一発で済まそうとせず、範囲を絞って何度か実行するような SQLでメンテナンスしたほうがトラブルを避けられます。また、範囲指定もインデックスを使うようにし、意図しない広範囲のロックを避ける必要があります。

OPTIMIZE TABLE は範囲を絞ることはできないため、メトリクスを監視しながら、クレジットが 50% を切るようであれば停止を検討したほうが良いでしょう。

OPTIMIZE TABLE に限らず、10分以上かかるSQL の場合は、AWSコンソールから上記 EBS Byte Balance 、EBS IO Balance、 Burst Balance、 CPU クレジット残高、バイナリログのディスク使用量、またリードレプリカの遅延 のメトリクスを常に監視し、クレジットの使い切りを発生させないようにしてください。

こんにちは、品質管理チーム (QCチーム) の渡辺です。
ちょっと遡りますが、わたしがQCチームに初めて配属時とこれまでのお話をしましょう。

どこにでもシステムは組み込まれている

 わたしはこれまでは運営業務のお仕事が中心でした。
リアル店舗では接客、商品仕入れ、コーナー作り、特典作成、Web店舗では通信販売、電子書籍販売、バナー、サイトページ、企画などのページ作成、またカスタマー業務と幅広く携わってきました。
　お勧めの作品がお客様の目に留めてもらうために、工夫を凝らして試行錯誤して、作品の売行きが好転すると、次回も頑張ろうと意欲が湧くものでした。
そのために、システム開発者に協力をお願いし、サイトのレイアウトや企画を伝えては、変更やシステム開発をしてもらっていました。
漫画のコマをページに載せたり、スクロールしても付いてくるキャラ画像を設置してもらったり、特典のダウンロード機能を付けてもらったりと、工夫を凝らしたシステムを作ってもらい導入してもらいました。
現在も漫画全巻ドットコムサイトで継続されている全力推し宣言もその一環でした。数年後にお勧め作品がすべてアニメ化になった時は、心の中でガッツポーズしたものです。
わたし自身のWeb業務は、HTMLタグで色や文字を変更したり、時にはサイトのプログラムリニューアルで当時人気のBootstrapに切り替える作業や自社レジ作成のお手伝いをしていました。そんな中で、Web初心者よりは“Webを理解している”と思ってました。

　ご興味あればこちらから　⇒　漫画全巻 全力推し宣言ページ

あの頃のWeb知識は初心者と一寸法師の背比べ

昨年10月にQCチームが立ち上がり、配属されたわたしは、今までの経験が活かせると大いに喜びました。
なぜかというと、業務内容が「デバッグ作業」という、サイトの中でお客様が検索や購入する操作をセッションごとにテストいき、操作中に不具合は出現しないか、レイアウトは崩れていないか、バグ発見次第に開発者へ報告する、ということだったからです。
また「開発中システムのテスト検証」もお客様にみせるサイトに関わる事なので、どちらもいままでの経験が役立っています。
そしてもう一つのミッションが「セキュリティ強化対策の検証」です。
この３つの業務を通して、システム開発者のお話を聞く機会も増えてきて、ようやく、わたしの持つWeb知識があまりにも少なくまた基礎が無いことが気づきました。開発者では良く会話の中に登場するAPI、プロトコル、AWSなど、単語の意味が分からない。いまや小学生から習う“インターネットの仕組み”も理解していませんでした。

Web知識は本から取得するのも一つの手

　そんな時に上司より良い教材を提供された、SB Creative刊『イラスト図解式 この一冊で全部わかるWeb技術の基本』を読みました。
インターネットの基礎知識からセキュリティの脆弱性の脅威まで幅広く扱っていて、単語も調べられるので、とてもに役立っており、いまでも読んでいます。

本の詳細は出版社サイトへ⇒『　イラスト図解式 この一冊で全部わかるWeb技術の基本　』

読んでいくとスマートフォンでおなじみの「アプリ」画面は、chromeの画面と同じ「ブラウザ」であるなど、目から鱗なお話もあり、面白いです。
まだまだ、初心者に毛が生えたレベルのわたしですが、ここからもっと知識を蓄えて開発者たちの会話が分かるように努力していきます。