何らかのキャッシュレス決済手段を導入している店舗の割合は、80%であった。クレジットカード、電子マネー、コード決済の全てを導入している店舗は23.4%となっており、店舗のおかれた状況により、導入する決済手段を選別していることがうかがえる。とりまとめより)顧客単価が高まるにつれクレジットカードの導入率が高まり、反対に顧客単価が低い店舗ではコード決済の導入が進んでいる。顧客単価が5,000円以下となるとキャッシュレス決済そのものの導入率が低くなることが示されている。店舗がキャッシュレス決済を導入した結果として、「レジ決済時間の短縮」といった効率化に関する要素が大きい。約半数の店舗では効果を実感されていないこともわかった。解放される」特性があると分析している。デジタル化され、請求データに基づき精算が自動実行されるもの」と設定し、キャッシュレスの社会的意義を「『人々と企業の活動』に密接に関わる『決済』を変革することで、既存の課題を解決し、新たな未来を想像する」ことにあるとしている。キャッシュレスによって目指す社会キャッシュレスの目指す姿(将来像)に求められるコンセプトが、「支払を意識しない決済が広がり、データがシームレスに連携されるデジタル社会」となっていくと指摘している。じると想定されている。インターチェンジフィーの公開クレジットカードや他の決済方法の加盟店管理市場における加盟店・アクワイアラ間の加盟店手数料の交渉や、アクワイアラ間の競争を促進する観点から、自らがカード発行や加盟店管理を行わない国際ブランドにあっては、我が国においても、インターチェンジフィーの標準料率を公開することが適当である等の考え方が示されている。Auroraを利用しています。Connector/Jを利用していたのですが、1.3.0からフェイルオーバーのサポートをしなくなったので、乗り換え先を探していました。Base調べてみたら、aws-mysql-jdbcと、aws-advanced-jdbc-wrapperが選択肢として上がりました。どちらもAWS謹製なのですが、ざっくり言うと前者がJDBCドライバーで、後者がJDBCドライバーのWrapperでMySQLやPostgreSQLなどのJDBCドライバーと併せて使うものになります。先に挙げた2つのライブラリの検証をしました。結論から言うと、Read-Writeで接続先を振り分ける(読み込み時はReader、書き込み時はWriterに接続する)という要件を満たしているのが、aws-advanced-jdbc-wrapperだけだったので、これをを利用することを決めました。aws-mysql-jdbcのこれに関する議論はこちらで行われています。Connector/Jについても検証してみました。'com.mysql:mysql-connector-j'}フェイルオーバー実行フェイルオーバー実行すると、DB接続に失敗後に、降格した(WriterからReaderになった)インスタンスに接続しつづけるためread-onlyのトランザクションで書き込みしようとしていると怒られました。Auroraのフェイルオーバーには対応していませんでした。MySQLはクラスタリングされたMySQLデータベースを利用したアプリケーションにメリットがあります。driverをベースにしており、ドロップイン互換性があります。Auroraのための素早いフェイルオーバーをサポートしています。MySQLやオンプレミス環境のMySQLのための機能も含んでサポートしています。詳しいことは、公式ドキュメントを参照してください。常にクラスターエンドポイントに接続しているので、フェイルオーバーを実行後もそのままクラスターエンドポイントに接続し続けます。フェイルオーバー中に書き込みしていたコネクションは失われます。wrapperとして再設計されました。Auroraのようなクラスタリングされたデータベースの機能を活用するアプリケーションをサポートするために存在するJDBCドライバーを機能拡張したものです。Driverはいくつかのデータベース自身に接続する実装はしていないですが、ユーザが選択しているJDBCドライバーをAWSやAuroraの機能性をサポートを有効にできます。詳しいことは、公式ドキュメントを参照してください。ホストコネクション失敗のモニタリング。'com.mysql:mysql-connector-j'}フェイルオーバー実行クラスターエンドポイントを指定するだけで、ライターインスタンスエンドポイントとリーダーインスタンスエンドポイントを検出してくれます。連続的にデータ書き込み&読み込み用エンドポイントを叩き中のログを見ると、ReadOnlyのコネクションはReaderに接続していることがわかりました。念の為、CloudWatchメトリクスでDatabaseConnectionsを見てみましたが、ちゃんとReaderに接続されていました。フェイルオーバー開始から完了までほぼダウンタイムが発生しないことがわかりました。Bootアプリケーションで利用してみます。1.0と2.0の違いをChatGPTに聞いてみました。2.0は、AWSクラウドリソースをローカル環境でシミュレートするために使用されるオープンソースプロジェクトです。これにより、開発者はオフラインでAWSサービスをテストできます。2.0は、1.0に比べていくつかの重要な改善点があります。2.0は、より高速で安定したパフォーマンスが期待されるように設計されています。1.0に存在するいくつかのバグや問題が修正されています。2.0では、新しいAWSサービスと機能のサポートが追加されています。これにより、開発者は最新のAWS機能をローカルで利用できるようになります。2.0では、プロジェクトの構造とアーキテクチャが再設計され、より維持管理が容易になり、拡張性が向上しています。2.0では、各サービスが独自のプロセス内で実行されるようになりました。これにより、サービス間の依存関係や問題が軽減され、安定性が向上しています。2.0では、設定とデプロイメントのプロセスが改善され、より使いやすくなっています。2.0は、1.0と比べてアクティブな開発とサポートが続いており、開発者が新しい機能やバグ修正を利用できるようになっています。2.0は1.0よりも高速で安定し、より多くのAWSサービスと機能をサポートし、開発者がAWSアプリケーションをローカル環境でテストする際に優れた選択肢となります。LocalStackの料金体系は、無料と有料があります。有料版でしか利用できないAWSクラウドリソースもあります。Coverageに書いてあります。1.18.0Docker上でLocalStackを起動するDocker上でLocalStackを起動するために、次のdocker-compose.ymlを用意しました。DOCKER_HOST=unix:///var/run/docker.sock起動します。CLIのコマンドで、LocalStack内の全サービスにアクセスすることができます。CLIというものもあります。CLIのどちらかをインストールしてください。awscli-localクレデンシャルの設定クレデンシャルとデフォルトリージョンの環境変数を設定してください。AWS_DEFAULT_REGION="ap-northeast-1"このクレデンシャルはダミーなので、direnvを利用して、このリポジトリディレクトリのみ環境変数が適用されるようにしました。CLIのコマンドを叩いて動作確認をします。[]}これでLocalStackを利用する環境は整いました。SQSを利用してキューにメッセージを格納するコマンドラインアプリケーションを実装します。細かい実装は、GitHubをご覧ください。SqsClientをBean登録します。今回、LocalStackを4566ポートで起動しているのでエンドポイントを書き換える必要があります。}}SQSのキューにメッセージを格納する処理を実装。CLIのコマンドを叩いてキューを作成します。Bootアプリケーションを起動して、キューにメッセージを格納します。CLIのコマンドを格納したメッセージを受信できることを確認します。--queue-url=http://queue.localhost.localstack.cloud:4566/000000000000/sample-queue無事にLocalStackを利用してAWSクラウドリソースをローカル環境でシミュレートすることができました。Testcontainersを利用したテストコードLocalStackをサポートしているTestcontainersを利用してテストコードを書きます。SqsClientのクレデンシャル等をTestcontainers用のものを利用することで、テストコードを書くことができます。Fargate上で動いているJavaアプリケーションにDatadogを導入する手順をまとめます。Faragte上で動いているJavaアプリケーションにDatadogを導入する本記事では4についてまとめます。JibのGradleプラグインを利用してDockerイメージを生成しています。.datadog/)します。追加しないでください。予期せぬ挙動が生じる場合があります。」とあるので、classpathには追加しないようにしてください。Agent用サイドカーコンテナを追加します。dd-java-agentをDockerイメージに含めるように設定を追加build.gradleに、dd-java-agentをDockerイメージに含めるように設定を追加してください。Fargeteにデプロイし、Datadogダッシュボードで確認するとメトリクスが取れるようになります。使った通信のエラーハンドリングの仕方についてまとめます。{}リクエストパラメータで指定したステータスコードが400系、500系だったらエラーレスポンスを、それ以外は正常系のレスポンスを返すAPIです。APIにリクエストを投げてみます。ResponseErrorHandlerを実装したクラスでエラーハンドリングするエンドポイントです。error"}解説それぞれのエラーハンドリングについて解説します。DefaultResponseErrorHandlerでエラーハンドリングデフォルトだと、RestTemplateで通信して起きたエラー(ステータスコード400系か500系)は、DefaultResponseErrorHandlerでハンドリングされます。該当コードを見てみるとこのように実装されており、通信してステータスコード400系と500系が返ってくるとHttpClientErrorExceptionを継承した例外クラスが投げられます。}}なので、HttpStatusCodeExceptionをcatchして、エラー時のレスポンスをHttpStatusCodeException#getResponseBodyAsStringで取得しています。}}ResponseErrorHandlerを実装したクラスでエラーハンドリングRestTemplateで通信してエラーが発生した際に例外を投げてほしくないという場合には、ResponseErrorHandlerを実装したクラスを用意します。この例では、ステータスコード400系と500系が返ってきても何もしないように実装しています。}}そして、RestTemplateでこのErrorHandlerを利用するようにします。レスポンスボディとして返されます。ServerResponse.class);}レスポンスボディからはエラーかどうかを判断できないので、ステータスコードでエラーかどうかを判断しています。.body(e.getResponse());}まとめResponseErrorHandlerを実装したクラスでエラーハンドリングを行うと、例外処理を書かなくて良くなるなる反面、呼び出したAPIからのエラーレスポンスが失われるかなと思います。ステータスコードさえわかって呼び出す側のシステムでエラーレスポンスを完全に決める場合なら有効かなと思います。DefaultResponseErrorHandlerでエラーハンドリングする場合は、例外処理を書くのが億劫ですが呼び出したAPIからのエラーレスポンスを返すことができます。2.7.3について書いてあります。Frameworkを利用してアプリケーションを作りやすくしている仕組みのこと。Dataなどのフレームワークを利用する。Bootの大きな違いは、Starterという依存関係便利パックが提供されている&デフォルトの設定(必要そうなクラスのBean登録)がされていること。Startersアプリケーションを作るときにあったら必要であろう依存関係を含んだ便利パック。SpringとJPAを利用してアプリケーションを作りたいとなったら、spring-boot-starter-data-jpaを依存関係に追加すればよい。Starterを利用すると後述するauto-configurationの仕組みが提供されており、単にライブラリを依存関係に追加するよりも設定項目が減り、楽にアプリケーション開発が行える。公式のスターターはspring-boot-starter-*という名前になっており多くのIDEでそれに適した設定が入っているため、サードパーティのスターターは頭にspring-bootという名前をつけてはいけない。Bootアプリケーションにおけるエントリーポイントは@SpringBootApplicationで、これをメインクラスに付与する。@SpringBootApplicationはパッケージ最上位に置くのがよい。一般的なメインクラス。Bootの設定にはJavaベースの設定を推奨している。XMLを利用することもできる。アプリケーションに自動的に設定を行う仕組みのことである。@EnableAutoConfigurationまたは@SpringBootApplicationを付与すると、auto-configurationを有効にすることができる。デフォルトで全AutoConfigurationが適用されるが、以下のように書くとauto-configurationから除外することができる。{}@SpringBootApplicationについて@SpringBootApplicationは、@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScanを含み持つアノーテーションでこれらと同じ機能を提供する。ちなみに、複数の機能を持つアノテーションのことを複合アノテーションと呼ぶ。@EnableAutoConfiguration先に説明したauto-configurationを有効にする@ComponentScanこれが付与されたクラスの配下にあるクラスの@Component系のアノテーション(@RestController、@Serviceなど)が付与されているクラスをBean登録する。Frameworkのアノテーション@SpringBootConfigurationこのクラス自身をBean登録する。@Configurationとほぼ同じ機能ではあるが、インテグレーションテストを書く際に役立つ。configurationAutoConfigurationのクラスに@AutoConfigurationを付与するとBean登録される。2.7より前はMETA-INF/spring.factoriesだった)に列挙されている。AutoConfigurationImportSelector#getCandidateConfigurationsを参照。Annotationsauto-configurationクラスに書いてある@Conditonalに従ってBean登録が行われる。@Conditionalの仲間には次のものがある。Conditionクラスパスに指定したクラスがあるかないか。@ConditionalOnClass、@ConditionalOnMissingClass。JacksonAutoConfiguration.javaだと、ObjectMapper.javaがクラスパスに存在したらauto-configurationが適用される。Conditions指定したBeanがあるかないか。@ConditionalOnBean、@ConditionalOnMissingBean。RestTemplateAutoConfiguration#restTemplateBuilderConfigurerだと、RestTemplateBuilderConfigurerがBean登録されてなかったらこのメソッドでRestTemplateBuilderConfigurerのBean登録が行われる。環境プロパティによってBean登録が行われる。Conditions指定したリソースが存在したらBean登録する。@ConditionalOnResource。このようにresourcesにパスを指定する。ConditionsWebアプリケーションかどうか。@ConditonalOnWebApplication、@ConditionalOnNotWebAplication。その他、クラウドプラットフォームかどうかで判定する@ConditionalOnCloudPlatformなどもある。Serviceが対象。Language)で書かれたプロパティに応じてBean登録する。Bootの特徴であるAutoConfigureの仕組みを説明する。DIコンテナ(ApplicationContext)の作成ApplicationContextは、BeanFactoryを継承したアプリケーションの設定を提供する主要なインターフェース。メイン機能の1つにDIコンテナがある。spring.factories、AutoConfiguration.imports読込META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importsにauto-configureするクラス(@AutoConfigureをつけたクラス)を列挙する。以前はspring.factoriesに書いていたが、このファイルはauto-configureを利用するために必要なクラスを書くようになった(ぽい)これらに書かれたクラスを読み込む。Bean登録するAutoConfigurationクラスをソート定義された順序で、Bean登録するAutoConfigurationクラスをソートする。AutoConfigurationSorter#getInPriorityOrderで行う。Bean登録ConfigurationClassParser#processGroupImportsでDIコンテナにBean登録を行うapplication.properties(yml)についてapplication.propterties(yml)は、設定値を書くファイル。Bootが提供している設定値の一覧はここに書いてある。このファイルに書いても確実に設定されるわけではなく、@ConfigurationPropertiesが付与されたクラスに値がバインドされるだけである。設定が行われる条件は、次の2つが満たされていることです。バインドされる@ConfigurationPropertiesのクラスがBean登録されていることそのAutoConfigurationが有効となっていこと大抵、@AutoConfigurationを付与したクラスに@EnableConfigurationPropertiesも付与されている。AutoConfigurationが有効になっていればapplication.properties(yml)に書いた設定は適用される。これはDataSourceAutoConfiguration.javaの例である。Bootを起動すると見るこれのことで地味に変更がされ続けている。バナーは256色利用可能にカスタマイズバナーのカスタマイズ方法は3通りで、デフォルトバナーは3で実現しているおり、SpringBootBanner.javaが実装。]を置くresources/banner.txtを置くorg.springframework.boot.Bannerインターフェースを実装する優先順位SpringApplicationBannerPrinter#getBannerで表示すバナーを決定している。Bannerは一緒に表示可能。Generatorというサイトがある。第4版を読んで運用に必要な知識MySQLのプロセスアーキテクチャMySQLはシングルプロセス・マルチスレッドモデルのデータベース。psコマンドのauxや-elfなどのオプションではmysqldのプロセスは1つしか見えない。PROCESSLISTで確認できる実行時のオーバーヘッドや情報の粒度などからperformance_schema.threadsテーブルの方が推奨されているMySQLのパラメータMySQLにはたくさんのパラメータ(設定可能項目)があり、分類ごとにいくつかの特性を持っている。オンラインで変更が可能なパラメータと設定変更にMySQLの再起動が必要なパラメータがある。PERSIST_ONLYで変更されたパラメータはDATADIR/mysqld-auto.cnfにJSONの形式で記録されるこのファイルは管理者が直接編集することを想定していない。8.0系列は同一リリース系列内でも非互換性があるため、バージョンの選定は慎重にされなくてはならない。クライアントやライブラリのバージョンはMySQLサーバと同じかそれ以上であることが必須。その機能やその周辺に新規にバグが内在する可能性がある。現時点で確実に進められることは次の通り。目標復旧時間(RTO)に応じてベースとなるフルバックアップの間隔を決める増分バックアップの頻度レプリケーション構成を組んでいる場合、間違いなくマスターではバイナリログが出力されているが、これをマスターのストレージ以外の場所に保管しておくことが必要。マスターだけにバイナリログが保管されている(増分バックアップを取得しない)場合、MySQLが稼働しているマシンが完全に壊れ、ストレージからMySQLのデータはおろかバイナリログすら取り出せなくなってしまうと最後のフルバックアップの時点までしか復元できないリストアにかかる時間の見積もりフルバックアップの頻度を決める上で重要なのが「フルバックアップをリストアするのにかかる時間」と「一定期間のバイナリログを適用するのにかかる時間」。これらをできるだけ正しく見積もることは大切。データが更新される頻度)に依存するバックアップの運用計画に関するパラメータ増分バックアップの計画に大切なパラメータとしてbinlog_expire_logs_secondsという値がある。これは、現在のバイナリログがスイッチした時点で過去の古いバイナリログを削除するためのパラメータ。バイナリログがスイッチするタイミングは、max_binlog_sizeというパラメータで決定される。追記されていったバイナリログのサイズがこのパラメータで設定されて値よりも大きくなると、バイナリログのスイッチが発生する。スレーブ)のバイナリログに出力する。これによりマスターとスレーブで二重にバイナリログが保管され、バイナリログの喪失への耐性が上がる。モニタリング計画MySQLが機能を提供しているかどうかを確認する「死活監視」と、中長期的にリソースの利用状況がどうなっていくかを確認する「リソース監視」の2つが必要。死活監視MySQLの機能を提供するプロセスはmysqld。ログバイナリログリレーログ実際の運用作業パラメータチューニングすこしくらいパラメータを変更したところでパフォーマンスが劇的によくなることはない。事前に綿密な計算のもと、パラメータを算出するよりも運用中に効果を測定しながら継続的にパラメータの最適値に近づけていくことが大切。事前に計算しておくべきパラメータinnodb_buffer_pool_sizeは重要なオプションInnoDBのすべてのテーブルで利用されるバッファプール(メモリ上に配置)のサイズを指定するSELECTのときにキャッシュとして使われるのみならず、InnoDBのすべての操作を一度バッファプールを経由して処理されるため、あらゆるDMLやDDLの速度に影響を及ぼす。5.6とそれ以前は再起動が必要だった)クエリチューニングMySQLのパフォーマンス問題の多くはクエリ単位に分解して考えることがベター。パラメータのチューニングがせいぜい数倍程度にしかパフォーマンスの問題を改善できないのに対し、正しくチューニングされたクエリは数百倍から数千倍のパフォーマンスが出る。LIMITを省メモリで効率的に処理する最適化が働く。BY句をインデックスで解決できているか、いなかを判断するためにもスロークエリログまたはperformance_schemaを使うクエリの書き換えによるチューニングアプリケーション側の発行するクエリを変えることによって高速化するループ構造による繰り返しクエリN+1問題Nの数が十分に小さいあいだはアプリケーション側でも遅いと感じられることがなく、データの増加にしたがってNが大きくなったときに初めて顕在化するJOINを使ってSQLレベルで処理できる。BY狙いのキーを使った追加ソートを不要とする方法がある。VARIABLESを使用する。セッション変数は@@SESSION、グローバル変数は@@GLOBALそれぞれの要素として確認できる。STATUSコマンドMySQLサーバーの実行状態に関する値を表示。メモリやディスクの使用状態、接続数に関する情報などが含まれている。以前から20年以上にわかって提供し続けている枯れた機能レプリケーションの仕組みMySQLのレプリケーションの構成では「マスターとスレーブに同一のデータを用意する」「」マスターに更新SQLを実行する」「マスターからスレーブに更新SQLを転送する」「スレーブが転送された更新SQLの内容をリプレイする」ことでデータを同期する。「まったく同じデータを持ったMySQLに対して」「まったく同じSQLを実行すれば」「実行後のデータはまったく同じになる」という「結果整合性モデル」でレプリケーションは動作する。古くからあるこの方式では、「クライアントから更新SQLを受け杖ける(唯一の)サーバー」を「マスター」、「マスターから間接的に更新SQLの内容を受け取るサーバー」を「スレーブ」と呼び、その関係は非対称。Dumpと呼ばれるスレッドが待機しており、このスレッドがバイナリログの更新を検知してスレーブにバイナリログイベントを送信する。Dumpスレッドはマスターと接続しているスレーブに対応して1対1で常駐する。Dumpスレッドに対応する形でスレーブには「(スレーブ)I/O」が起動しており、この2つのスレッドがTCP通信でコネクションを開いている。コネクションからバイナリログイベントが送信されてくると、それをI/Oスレッドが受信してリレーログと呼ばれるファイルに記録する。スレーブにはさらに「(スレーブ)SQL」スレッドが常駐しており、リレーログの更新を待ち受けている。このSQLスレッドがリレーログからバイナリログイベントを取り出し、スレーブ上のデータに対してリプレイすることで、マスターとスレーブのデータが同一となる。このリプレイ時にスレーブにはスレーブサーバー常に新たにバイナリログを記録する。非同期レプリケーションと準同期レプリケーションの違いは、(主にマスタークラッシュ時の)データの永続性にあるデータの信頼性に対する観点では非同期レプリケーションがおすすめマルチソースレプリケーション「マスター多:スレーブ1」の構成のこと「ソース」はバイナリログイベントを受け付ける「元」を表す。多段レプリケーション構成スレーブがマスターから受け取りリプレイしたバイナリログイベントを、さらにスレーブ自身のバイナリログに記録することによって、「1次スレーブをマスターに見立てた2次スレーブ」を構築できる。「多段レプリケーション構成」、「カスケードレプリケーション」などと呼び、1次スレーブを「子スレーブ」「中間マスター」「中間スレーブ」、2次スレーブを「孫スレーブ」などと呼ぶグループレプリケーションのデータ同期グループレプリケーションでは「クライアントからの更新SQLを受け付けるサーバー」を「プライマリー」と呼びそれ以外のサーバーを「セカンダリー」と呼びます。「プライマリーが1台のみ選出されるシングルプライマリーモード」と「すべてのサーバーがプライマリーになるマルチプライマリーモード」の両モードが存在し、とくに後者の場合はマスター/スレーブ構成とは大きく異なる。更新SQLを受け付けたプライマリーサーバーはグループコミュニケーションエンジンに更新SQLの内容を渡し、各サーバーのグループコミュニケーションエンジン同士がサーティフィケーションと呼ばれる処理を経てリレーログに書き込む。サーティフィケーションは書き込みの競合チェックを行う処理で、異なるノードの同じ行に対して行われた更新を検出して、競合したトランザクションをロールバックする。コミットが先に行われたトランザクションのみが成功し、それ以外のトランザクションは失敗させることで一貫性が保たれる仕組みレプリケーションはデータの複製のための機能。マスターへの更新はバイナリログから始まる形でスレーブに非同期に差分更新される。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。