近年、公共交通の維持が難しい過疎地などを中心にデマンド型の移動サービスが注目されている。需要（リクエスト）に応じて運行される乗り合いタクシー・バスが代表例で、バス路線の維持が困難な地域や、タクシー料金の負担が大きくなりがちな地域において存在感を増している。 このオンデマンド型の移動サービスは、各地で開発が進められているMaaSにおいても導入が検討されている。「ドアtoドア」の利便性と公共交通などを組み合わせることで、郊外型や点在型観光地などにおいてより効率的な移動が可能になるのだ。 そこで今回は、オンデマンドモビリティサービスを開発する企業をピックアップし、開発状況や実例などに触れていく。

builderscon tokyo 2019で登壇した際の資料です。 Kyash Directのアーキテクチャについて - スクラッチ開発を決めた経緯 - アーキテクチャ決定までの試行錯誤 - 関連トピック - Microservices - DDD - AsyncMess…

This is the 3rd blog post for Mercari’s bold challenge month. At Mercari, while migrating our monolithic backend to microservices architecture, we felt the need to have a service mesh and understood its importance in the long run. Most of the incident post-mortem reports had actionable items such as — implement rate-limit, implement a better canary release flow, better network policies… and this i

マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ マイクロサービスにおける通信方式の選択について、おおた（ota42y）さんが、GraphQL・gRPC・OpenAPIといった主なWeb APIスキーマの管理の利点と使い分けを解説します。 近年流行しているマイクロサービスアーキテクチャにおいては、「どういった通信方式を選ぶか」が開発の効率やサービスの信頼性、パフォーマンスを大きく左右します。この記事では、GraphQL・gRPC・OpenAPIそれぞれの利点と適切な使い分けについて解説します。 マイクロサービスにおけるWeb API管理の重要性 Schema First DevelopmentとWeb API 人ではなくプログラムが処理できるよう管理する Web APIのインタフェース定義手法の比較 OpenAPI ─ R

昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが

MVPは最低限の機能しか作らないので、ブラッシュアップするのが前提にある。 なので変更しやすい方がいい

Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWS Serverless Application Model 資料及び QA 公開 先日 (2019/08/14) 開催しました AWS Black Belt Online Seminar「AWS Serverless Application Model」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190814 AWS Black Belt Online Seminar AWS Serverless Application Model AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS SAM CLI 自体を Docker コンテナの中で実行することは可能でしょうか？ A. Docker コ

IT基盤部エンジニアブログリレー第4回目。 こんにちは、IT基盤部ネットワークG torigoe です。 オンプレとクラウドのネットワークをどう繋げるのか、クラウド内のネットワークをどうするのか考えた話を書きます。 多くの内部サービスを持っていて、オンプレからクラウドに移行を検討しているネットワークエンジニアの人に読んで頂ければと思います。 はじまり 2018年ある日、mtgに呼ばれて急に DeNAのインフラ全てをオンプレからパブリッククラウド(しかもマルチ)に変えようと思うがどうよ？ と言われました。正直その日まであまりパブリッククラウドサービスを触った事がありませんでしたが、説明された内容には納得できたのでそんな事は噯にも出さず同意し、次の日からオンプレ-クラウド移行の為に必要なネットワークの検討を開始する事になりました。(元々Openstackは触ってました) まずはAWSを色々と触

ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ

Amazon Web Services ブログ 【開催報告】AWS re:Inforce 2019 re:Cap Seminar 2019年7月30日、AWS Loft Tokyo にて、AWS re:Inforce 2019 で発表・紹介されたセキュリティサービスやソリューションの最新情報を振り返るイベントが開催されました。 AWS re:Inforce 2019 とは、2019年6月25、26日に米国ボストンで開催された AWS セキュリティ&コンプライアンス最大のカンファレンスです。エンドユーザー様、パートナー様を中心に、世界50カ国以上中から8,000人以上の来場者が集まりました。基調講演や170を超えるセッション、パートナー様展示ブースからなる Security Learning Hub、参加者同士のネットワーキングイベントなどからなるとても大きなイベントでした。 そこで本セミナ

- The document discusses monitoring AWS resources using Amazon CloudWatch. It covers collecting metrics and logs from EC2 instances, ELB, RDS, and other services and visualizing the data in CloudWatch. - Key services mentioned include CloudWatch Metrics to collect CPU, memory, disk and network utilization from EC2 instances, CloudWatch Logs to collect logs, and integrating monitoring with services

データベースの機能で複数のライターを選択します。これがAurora Multi-Masterの選択になります。 各々の項目に任意の内容を設定します。 DBインスタンスサイズは、以下の3種類から選択できます。 db.r4.2xlarge db.r4.4xlarge db.r4.8xlarge マルチ AZ 配置で別の AZ で Aurora レプリカ/リーダーノードを作成するを選択してデータベースの作成をクリックします。 しばらく経つとAuroraクラスタが起動します。 基本動作の確認 EC2を起動してログインします。ここではAmazon Linux 2で起動しています。 MySQLクライアントをインストールします。（Amazon Linux 2なので実態はMariaDBですが） $ sudo yum install mysql -y まずは、各々のエンドポイントの状況を確認しています。クラ

TL;DR; Engineering Managerを降りることになりましたので、振り返りとまとめです。 ※会社は辞めませんので、退職エントリではございません（別チームへの異動です） 時系列 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い 2018/04: SREのEngineering Managerに登用される 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた 2018/10: 2チーム兼任からMicroser

最近、社内でよく話をする内容についてまとめました。 企業がOSS化するといろいろメリットがあると思っていて、社内でもそこのコンセンサスはうちの技術横断部門のメンバー間では取れていたりするのですが、自社以外の人とかと話をする時もあるので、いろいろまとめておきます。 なお、この文章では本業をOSSにしつつビジネスを回そうみたいなElasticsearchとかMongoDBとかMySQLみたいな話題はとりあげず、本業が別にある会社がOSS化する、という部分に特化した話です。 9/13に追記 よく言われるメリットとデメリット メリットは、公開することで開発が自然と進み、コスト削減になる。一方でノウハウの流出などのデメリットがある、みたいなトレードオフ、という理解をしている人が多いようです。 コストは削減にならない OSS化したら多くの人に使ってもらいたいですよね？というのは考えるわけですが、その「

アジアパシフィック (シンガポール、シドニー、東京) のリージョンで、AWS IoT Core と AWS IoT Device Management の料金が値下げされました。 AWS IoT Core の料金は、アジアパシフィック (東京) リージョンで 15% 以上、アジアパシフィック (シンガポール、シドニー) リージョンで 20% 以上引き下げられ、アジアパシフィック (ソウル) リージョンと同じ料金になりました。 AWS IoT Device Management の料金は、アジアパシフィック (東京) リージョンで 20% 以上、アジアパシフィック (シンガポール、シドニー) リージョンで 37% 以上引き下げられ、アジアパシフィック (ソウル) リージョンと同じ料金になりました。 この新しい料金は、2019 年 8 月の請求サイクルから適用されます。これによって、お客様のコ

Random Facts club is a podcast for things useless for your work