Meet Magento Japan 2019 講演レポート<後編>

November 05, 2019
=2019年11月5日に都内で開催された「Meet Magento Japan 2019」。当日行われたコウェル社員による講演の内容を前編・後編に分けてレポートします。=
MeetMagentoJapan様子
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Speaker Information>>
後藤 香織(Goto Kaori) Quality Assurance Solution Div Director CO-WELL Co., Ltd.
・SIerにてエンタープラシステムの開発に従事
・第三者検証会社にてWebから航空宇宙まで幅広い品質保証業務に従事
・Web特化の事業、テスト自動化事業の立ち上げを担う
・2019年コウェルにJoinし、ソフトウェアテストのソリューションを立ち上げ現在に至る。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
|講演テーマ|大規模Magentoプロジェクトにおけるベトナムオフショアのテストの現場から
1)プロジェクト概要について
Magento後藤写真
私のセクションでは、テストサービスという観点からお話します。今回のプロジェクトの概要は、ネットスーパーのフルリニューアルプロジェクトになります。
ベース機能のマイグレーションに加えて追加機能の開発、同時にパフォーマンスの改善を実現も行いました。解決したい課題としては、高コストシステムからの脱却(ライセンス費用、開発、運用、保守)、老朽化からの脱却(ハード及びミドルウェアの保守切れ)、フロント変更改修が容易なシステムの導入となります。

今回のプロジェクトの特徴としては、規模でいうと日本国内最大規模のMagento活用事例となり、数百のマルチサイト構成、SKU数2000万強となり、Magentoが当初想定したボリュームよりはるかに多いものだったのではないかと思います。インフラ面では、様々な規制の中でAzureを選定となりました。
開発プロセスは、アジャイルとウォーターフォールの組合せで進めました。ロードマップとしては、2017年8月から要件定義が始まりアジャイル開発へとシフトし、UATからウォーターフォールに変更し2018年8月から地域限定でリリース。その後、全国展開へ至ったのは2019年6月、9月には軽減税率対応があり、現在は保守フェーズとなっています。トータル開発期間は2年強となり、当社でもMagento案件で最初にして最大のプロジェクトとなりました。途中様々な問題や課題がありましたが、最初にこのボリュームの案件に関われたことでかなりの知見をチーム全体で得ることが出来ました。

この開発体制についてですが、プロジェクト参加人数は最大約100名/月、ベトナム側開発チームは開発機能毎に1チーム10〜15名程で構成し、最大7チーム程が同時に開発、テスト業務を実施を行いました。
2)プロジェクトの苦労と対策について
一番問題が大きかったのは、Magentoが想定する規模を超えた大規模開発(2700万SKU)であり、性能上クリティカルな問題が多発したことでした。これに対して、DB構成見直しやコアロジック修正を行いました。 また、性能問題の対応でデグレードが発生し、高頻度かつ広範囲に対するテストが必要だったため、 データ比較ツール、テスト自動化ツールの導入による効率化で対応しました。 その他、テストのデータパターンや量が多くデータ作成に時間がかかる課題ができました。これについては、テスト自動化ツールをデータ作成にも活用し効率化をはかったり、基幹システムとの連携が多く、データ構造やインターフェースが合っていない問題については、 ECサイト側で基幹システムに合わせて改修を行いました。

課題対策について、もう少し詳しくお話ししましょう。
①Magentoが想定する規模を超えた大規模開発(2700万SKU)であり、性能上クリティカルな問題が多発この問題は、商品データの1/10程度の投入でまともに動かなくなり、デッドロックが多発したことです。
理由として考えられるのは、データ構造がEAV形式になっており、データ量が大きくなりやすいこと、標準のSQLの中に一回のクエリが重いものがある、関連するあらゆるデータを更新、ループ処理時一回の処理で数万回のSQLが実行されるなどです。
これに対しての対策は、DBサーバーのスペックを大きくし、データ量の増加に対応。標準で用意されている機能の中で性能上フィットしないものは独自にカスタマイズして対応を行いました。

②性能問題の対応でデグレードが発生
この問題は、コアロジックに手を入れたため、影響範囲の特定が困難になったことです。
課題としては、高頻度かつ広範囲のテストを実現する手段が必要がありました。
これに対し、データ比較ツールを作成し現新比較を実施し、( ※DB格納データが改修前と変わらないことを確認)管理機能側(直接改修しない)については自動テストを実装し、フロントエンド側の改修による影響がないことを常に確認しました。

③テストデータパターンや量が多くデータ作成に時間がかかる
テストデータパターンが多いことが問題でした。要は、地域、商品、決済方法などテストすべきバリエーションが多く、データパターンをたくさん用意する必要があるのです。それに対して自動テストツールをデータ作成にも活用することで対応しました。

④基幹システムとの連携が多いが、データ構造やインターフェースが合っていない
基幹システムとデータ構造が合わず連携できない問題について、データ構造を合わせる必要があるが、基幹システムに手を入れることはできない(データマッピング取り込むときに補正してくれない)状況でした。これについてECサイト側でデータの持ち方を合わせ対応しました。※ECシステム上必要ないカラムを追加するなど
3)テストチームとしての工夫
Magento後藤写真
最後に当社のテストチームとしての工夫をご紹介して終わります。ここでの重要なポイントは「人、仕組み、ツールで品質リスクをコントロール」することです。
大切なのは、「何をテストするか」「そのような手段でチェックするか」「どう効率化するか」です。
■<ハイスキル人材による質の高いテスト設計>
 複雑なテスト条件が多いため質の高いテスト設計を行うために、テストのスペシャリストを中心にテストチームを構成。
■<DBレベルの現新比較の導入> 
性能改善など影響範囲が見えない改修を安全かつ効率的に行い、 ※意図した変更がされているかどうか?意図しない変更がされていないかどうか?を確認するためのDBデータ自動比較ツールも開発。
■<プログラミングレスの自動化ツールの導入>
 膨大なテストを効率的に実施すべく、改修の手が入らないバックエンド側は自動テストにて常時リグレッションテストを行った。
→ フロントエンドのテストに注力できるようになった。 ※プログラミングレスで実装できる自動化ツール(WEBIUM)を内製して大幅に工数削減に成功。

そろそろまとめに入ろうと思います。これまで述べてきたように、グローバル開発にはMagentoが向いていますが、超大規模開発ではパッケージのカスタマイズが必要なケースがあります。特に性能周りは注意が必要です。
EC開発では外部連携が複雑になる傾向が高いため、あらゆる条件を想定した複雑なテスト設計を要すため、テスト設計にはスペシャリスト人材が必須です。
又、性能改善後の品質チェックにはDB比較が効果的で、改修を行わない箇所(今回はバックエンド)はテスト自動化による効率化が向いています。※テストチームに自動化実装スキルを持った人材がいない場合は、コーディングレスのツールを活用すると良いですね。
Magento2019様子
pagetop