一般企業であまり前例がない「認証VLAN」を導入した、その後の学び - MonotaRO Tech Blog
こんにちは。サービスインフラ-Bグループの宮本・高野です。 今回はManabiCon第3回で発表した「梅田オフィスで認証VLANを導入したプロジェクト」について紹介します。 自己紹介 梅田オフィス構築後に発生した問題 前提 フリーアドレス 通信品質の安定 本題 そもそもVLANとは何なのか？ じゃあ認証VLANとは何なのか？ 認証VLANのキーワード「IEEE802.1X」とは？ プロジェクト概要 プロジェクト体制 プロジェクトの予定期間 実現したいこと 検証時の苦労 苦労したことその1: 必要機材とテストパターンの洗い出し 苦労したことその2:検証環境の構築 苦労したことその3:VLAN設計変更 苦労したことその4:有線LAN接続時、通信が不安定になる 苦労したことその5:認証VLANを利用しているPCへリモートデスクトップ接続ができない 在宅勤務・出社勤務 802.1X の認証モードに
【Elasticsearch】1900万点に及ぶ商品データ作成の時間を約67%短縮できた構成と工夫 - MonotaRO Tech Blog
初めまして、EC基盤グループ サーチチームの壷井です。 モノタロウでは2019年10月頃より新規検索システムの設計・開発を進め、今年の4月頃にECサイト(monotaro.com) 検索ページの裏側の検索システムを従来のSolrからElasticsearchに100%移行*1しました。この移行は将来の商品点数やリクエスト数の増加を見据えたバックエンドの大規模な改修で、ここまで約2年半ほどプロジェクトを進めてきました。今後もECサイトのすべてのページの完全移行に向け引き続き開発・運用を行っていきます。 今回はこのプロジェクトのなかで私が担当してきたElasticsearchへの日々のデータの洗い替え（日次更新と呼んでいます）ワークフローのシステム構成と工夫などについてお話します。 モノタロウの検索システムの紹介 日次更新のシステム構成 処理の流れ ① リアルタイムデータ同期 ② 日次商品デー
Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。 - MonotaRO Tech Blog
序文 こんにちは。MonotaROの伊藤です。 弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います 序文 運用担当者の負荷が高まり続ける問題 運用担当者=社歴が長いベテランエンジニア 運用のスケールアウト 障害対応訓練をやってみよう 訓練環境の準備の問題 訓練シナリオの問題 外部からの助け Wheel of Misfortuneとは 実施時の様子 シナリオ開始時の様子 モニタリング画面の表示 WoMとDiRT(Disaster in Recovery Training) 障害対応訓練をやってみた結果 準備時点で感じたメリット 手順書の不備を発見できたこと 障害が起こりかねない場所を考えるきっかけになったこと
モノリシックなアプリケーション開発から小さなアプリケーション開発へ（Software Design連載 2022年3月号：設計方針から変えていく、 モノリシックなアプリの過去と未来） - MonotaRO Tech Blog
この記事の初出は、Software Design2022年3月号「設計方針から変えていく、モノリシックなアプリの過去と未来（最終回）」で、加筆修正されています。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog 第3回 Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog 第4回 Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Te
「Magento」を使って1,400万商品を取り扱えるように越境ECサイトをパワーアップした話 - MonotaRO Tech Blog
モノタロウで海外向けのECサイト開発を担当している山田です。Tech Blogでは、これまでに国内サイトの開発・運用を効率化する様々な取り組みを紹介してきましたが、今回はモノタロウの海外事業に関する取り組みについて、特に、Magentoを活用したモノタロウの越境ECサイト開発と運用にスポットを当てて紹介します。 MonotaROの海外事業 MonotaROの東南アジア向け越境ECビジネスについて Magentoとは Magentoで越境ECサイトをリプレイスした背景 Magentoによるサイト開発・運用の効率化事例 エクステンション導入による開発の高速化 ベスト・プラクティスに沿った開発手法の提供 カスタマイズに対して堅牢性の高いアーキテクチャを提供 効率的に開発が行えるコーディング手法の提供 品質保証のための枠組みをデフォルトで提供 公式ドキュメントの活用によるMagentoの効率的な学
MonotaROのデータ基盤10年史（前編） - MonotaRO Tech Blog
おしらせ：12/23 に後編記事がでました！ tech-blog.monotaro.com こんにちは、データ基盤グループの香川です。 現在モノタロウではBigQueryに社内のデータを集約し、データ基盤を構築しています。 およそ全従業員の6割が日々データ基盤を利用しており、利用方法や目的は多岐に渡ります。 データ基盤グループはこれまでデータ基盤システムの開発保守と利用者のサポートを主な業務として取り組んできましたが、これら多岐にわたる社内のデータ利用における課題の解決及びさらなるデータ活用の高度化を目的として、今年の5月よりデータ管理を専門に行う組織として新たに体制を再構築しました。 そこで改めて組織として取り組むべき課題や方向性を決めるために、まず自分たちの現在地を知ることが重要と考え、データ基盤の歴史を振り返り、社内のデータ活用における課題やそれを取り巻く状況がどう変わってきたのかを
Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog
こんにちは、辰巳です。 第3回は「スナップショットテスト」をテーマにお送りします！ 「組織が拡大する中で、十分な設計情報がない状況でも、複雑に改修が積み重なったソフトウェアをいかに安全かつ正確に変更できるか？」 本記事では、数多くの大幅なシステム変更の経験を経て、この課題に対してモノタロウがいま実践しているグッドプラクティスを紹介します。 本記事の初出は、 Software Design2021年10月号「Pythonモダン化計画（第3回）」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 スナップショットテストの可能性を追求する モノタロウは、事業者向けの間接資材を販売
Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画（第1
スケールアウトの落とし穴から学ぶ、SREチームでのダッシュボードのアップデート術 - MonotaRO Tech Blog
どんなことが起こったのか？ モノタロウのサイトの監視について レイテンシ監視 トラフィック監視 エラー監視 リソース監視 ログ トラブルシュートの進め方 発生検知 発生箇所の特定 根本原因の調査 強化 課題 おわりに SREチームの市原(@ichi_taro3) です。 モノタロウでは、www.monotaro.com という大規模なECサイトを自社で開発、運用しています。 Webアプリケーションの運用ではトラブルはつきものです。今回は、とあるトラブルシュート事例を軸に、どのように運用を改善しているのかについて紹介します。 どんなことが起こったのか？ あるとき、モノタロウのWebサービス全体でレイテンシ悪化やバックエンドAPIへのタイムアウトの増加が頻発したことがありました。 当然これらは歓迎される状況ではなく、すぐに開発者やSRE、インフラチームの担当者が集まり調査を開始しました。現象は
20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
