はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの長尾です。 WEARは2013年にリリースされ、現在8年目のサービスです。そして、2004年にリリースされた当時のZOZOTOWNと同じアーキテクチャを採用しているため、比較的古いシステム構成で稼働しています。本記事では、そのWEARのWebアプリケーション刷新とクラウド移行で実践している、Fastlyを活用したパスベースルーティングによる段階移行の取り組みを紹介します。 WEARをリプレイスする理由 WEARのWebアプリケーションは、データセンターでオンプレミス（以下、オンプレ）上で稼働しています。また、DBはSQL Serverを利用しています。長年このアーキテクチャで成長を続けてきましたが、今後さらに成長を加速させていくためには以下の3点を実現する必要があります。その実現に向け、2年前からリプレイスに

どーもsutoです。 SlackのスラッシュコマンドからLambdaをスパッと実行させるためのAPI GatewayとSlack APIを設定する手順を備忘録として記事に残しておこうと思います。 Lambda作成について 本記事では検証用として使用するLambdaは、以前の記事で作成したものを流用させていただきます。 Lambdaの作成とコードは以下から。 API Gatewayの作成 APIの画面から「REST API」を選択します。 「新しいAPIの作成」を選択し、任意のAPI名を入力しAPIを作成します。 次に「アクション」から「メソッドの作成」→「POST」を選択します。 統合タイプに「Lambda関数」を選択、実行対象のLambda関数名を入力し保存します。 次に、「統合リクエスト」から「マッピングテンプレート」を設定します。Slack apiから送られてくるリクエストのCont

前回は Jenkinsfile を書く上で知っておくべきセキュリティ上の制約について紹介しました。 arasio.hatenablog.com 今回は、機能上の制約を書きたいと思います。 ここで言う機能上の制約とは、Jenkins がジョブの一時停止/再開機能を実現するために、代償としてパイプラインでは使えなくなっている Groovy の制約のことです。 一時停止/再開機能をどう実現しているかを説明してから、それに起因する制約と回避策を紹介します。 ジョブの一時停止/再開 パイプラインジョブは実行中に一時停止し、そこから再開することができます。 これを実現するために、パイプラインスクリプトはそのままコンパイルされるのではなく、 Jenkins 内部で持っている Groovy インタープリタで処理されます。 そして、一メソッドずつ命令を実行し、スタックなども含めたプログラムの状態を逐一永続化

マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント：特集：マイクロサービス入門（終） マイクロサービスアーキテクチャへの移行を進める上で生まれた課題にどう取り組んだのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行後のテスト、CI/CD、運用監視を紹介します。 これまでの連載では、ECサイトであるOisixをマイクロサービスアーキテクチャへ移行させていくアプローチについて解説してきたが、今回は移行させた後の開発・運用について解説する。 併せて前回まで触れてこなかった開発時に留意しておいた方がいい継続的なメンテナンスや運用に関する内容についても解説する。 CI/CDパイプラインを生かした機動力のある開発 本連載の第5回でも「パイプラインファースト」という言葉について説明したが、開発当初からCI/CD（継続的インテグレーション／継続的デプ

マイクロサービスアーキテクチャへの移行を進める上で生まれた課題にどう取り組んだのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行のハードルにどう取り組んだのか紹介します。 Oisixは2000年の創業以来、一度も全面的なシステムリプレースを行わず、システムの改修を続けてきたECサイトだ。マイクロサービスアーキテクチャへの転換を検討し始めた2017年時点で、17年以上も創業当時のアーキテクチャのまま、運用を続けてきたというわけだ。 今回はそのOisixをマイクロサービスアーキテクチャに移行する上で生まれた課題にどう立ち向かったのかを解説する。 既存システムの分析と改善 システムアーキテクチャを刷新する上で、まず最優先に取り組むべきなのはそのシステムが構成する業務の分析／再定義になるだろう。 システムの現状分析を基に、開発、運用のプロセスあるいはサービス提供をする上でのボ

新規構築や移行時のリスクを軽減、「ストラングラーパターン」とは？：特集：マイクロサービス入門（5） モノリシックなサービスをマイクロサービス化する際、どのように移行させればいいのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行に当たって採用したアプローチと開発プロセスを紹介します。 今回は、ECサイトのOisixをマイクロサービスアーキテクチャへ移行するに当たって採用したアプローチを紹介する。OisixはJavaによるServletベースのWebアプリケーションで、画面表示にはJSP（JavaServer Pages）を用いている。このシステムをマイクロサービス化するに当たって、以下の構成になるよう目指した。 バックエンドの業務ロジックを全てステートレスな「RESTful API」として実装する フロントエンドの実装をアプリケーションサーバから分離する 迅速にサービス

This domain may be for sale!

Android開発者向けカンファレンスDroidKaigiも今回2018で4回目を迎え、1,000人近くの参加者、80以上のセッションを擁する大きなイベントとなった。 今年も去年に引き続き、登壇者として採択いただくことができた。今回は、昨年の「Android Bikeを作ろう」(Android端末のセンサーとBluetooth LEデバイスを使ってサイクルコンピューターを作ってみようという話)から一転、今年は普段アプリのビルドに使っているGradleのプラグインの作り方を解説するセッションをやらせていただいた。 登壇することになった流れから、資料作成のあれこれ、実際発表してみた感想までを軽く振り返ってみたいと思う。 内容 Androidのビルドで必ずお世話になるbuild.gradle. いろんな設定が書けて便利ですよね。だけど、あちらこちらのプロジェクトで同じような設定をコピペしてない？

100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順 マイクロサービスの導入事例を、中の人が徹底的に語ります。クックパッドでは、100万行オーバーの超巨大なRuby on Railsアプリのマイクロサービス化に挑みました。アプリをいかに分離し、連携できるようにするか、など、同社が採ったマイクロサービス化の戦略を聞きました。 Ruby on Railsのバージョンアップに1年かかっていた 【マイクロサービス化戦略】まずはコードを減らすことから 【マイクロサービス化戦略】アプリ固有のバッドノウハウを減らす 【マイクロサービス化戦略】まずは分離しやすい部分からお試しで 【マイクロサービス化戦略】データベースが切れていればサービスも切りやすい 【マイクロサービス化戦略】インフラ構成を標準化する 【マイクロサービス化戦略】サービスメッシュを入れて通信の課題をクリ

大栗です。 1月にAWSのSLA対象サービスが大量増加したエントリを書いたのですが、3月にもっと大量になって、全体的に内容も変わっていたので一覧表にまとめたいと思います。 AWS Service Level Agreements 著者の拙い英語力を基に調査しているため内容に不備があるかもしれません。詳細はSLAの本文（英語版）をご確認ください。 AWSにおけるSLA AWSのサービスレベルアグリーメントは基本的に、定義された可用性以上で使用できるようにするため商業的に合理的な努力をAWSがするものです。サービスレベルを"Assurance"（保証）ではなく"Agreement"（合意）するものです。またSLAの対象となるためには基本的にAWSのベストプラクティスに従っている必要がありますので、対象システムの構成を確認しましょう。 SLAで定義されている可用性を下回る場合には、利用費に対する

前回の続き JUnitの Extension インターフェース JUnit4のRunnerと同様、JUnit5も拡張をすることができる。 JUnit5が提供している 拡張インターフェース(Extension を継承したインターフェース)は次のとおり。 ContainerExecutionCondition メソッド - evaluate(ContainerExtensionContext) 戻り値の型 - ConditionEvaluationResult テストクラスレベルで実行可否の判断する TestExecutionCondition メソッド - evaluate(TestExtensionContext) 戻り値の型 - ConditionEvaluationResult テストメソッドの実行可否の判断する BeforeAllCallback メソッド - beforeAll(C

2019年7月22日のJAWS-UG アーキテクチャ専門支部での発表資料です。 引き続き、議論・更新していきたいと思います。 (運用設計ラボ合同会社 波田野裕一)

スマートキャンプのエンジニア瀧川です！ クライアントサイド(JavaScript)で処理を定期実行したい場合は皆さん使いますよね！ そうsetInterval関数です。 ただ何も考えず使ってしまうと色々な問題が起こったり... そこで本記事ではsetInterval関数を使う際の困りごとを挙げて、それをまるっと解消するVue.jsプラグインを作る方法を紹介したいと思います！ (今回はVue.jsで実装しますが、特に依存しているわけはないので他のフレームワークをお使いの方も参考にしてください！) まずVue.jsプラグインの雛形を作る 困りごと1 困りごと: ブラウザ(タブ)を開きっぱなしにすると必要以上に実行されてしまう 解決法: Page Visibility APIを利用してアクティブなときにしか処理を実行しない 困りごと2 困りごと: ページ遷移してもsetIntervalが維持され

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

備忘録。書きかけ＆未確認。 現在の作業リポジトリの変更をすべてコミットしておく これで失敗しても安心♡ trunkの内容をbranchにmerge 作業リポジトリをbranchに変更 svn switch file:///home/sysdev/svn_repos/branches/branched_version svn infoコマンドで現在の作業リポジトリのURL等を確認しておくこと。 branchの開始点のリビジョン番号を確認 svn log --stop-on-copy 一番最後に出力されるログのリビジョン番号を控えておく（仮にr411とする）。 trunkの内容をbranchにmerge（merge試行） svn merge --dry-run -r 411:HEAD file:///home/sysdev/svn_repos/trunk trunkのr411から最新までのコミ