"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
マイクロサービスにおける内部通信の認証について
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
サイドカーライブラリ Dapr の分散トレーシングを試す - kencharosの日記
ちょっと前にこんなニュースがありました。 www.publickey1.jp 公式はこの辺かな? dapr.io github.com Microsoft が OSS で、しかも golang で作ったという異色のライブラリです。 また最近は envoy を使ったサービスメッシュについて色々と調べていたこともあり、似たような問題を解決するものであるといこともあり、興味を持ちました。 サンプルやコンセプトページを見ているとなんとなく雰囲気がつかめてきます。 github.com github.com Isito のように、各サービスにサイドカーとして起動するDapr インスタンスとサイドカーインスタンスを管理するDaprサーバーから構成されている。 サイドカー経由でサービスにアクセスすることでアドレス解決を任せたり、プロトコル変換ができる。 例えば、HTTPしかないサービスをgRPC経由で呼
Consul Connect - 理系学生日記
Consul Connect の資料を一通り読み終わったので、簡単に Connect についてまとめてみます。 ちなみに、全貌がいちばん分かりやすかったのは、HashiDays 2018 の Keynote でした。 概要 Consul Connect を構成する 3 つのコンポーネント Service Access Graph Certificate Authority Pluggable Data Plane まとめ 概要 Consul Connect とは何かというと、 サービスとサービス間の通信を mTLS で暗号化するとともに「認証」を行い、 論理的なサービス名を用いた通信の「認可」制御を行える機能 なんじゃないかと思います。 つまりはサービス間通信の認証・認可を、(基本的には)アプリの変更なしに Sidecar Pattern で実現しようという機能です。 そして、その大きな目
ECSのサービスディスカバリーが東京にやってきて、コンテナ間通信の実装が簡単になりました！ | DevelopersIO
つまりは、オートスケールやタスク数設定によるコンテナ増減に連動して、Route 53のレコードが自動的に書き換えられるということすね。 従来から存在したRoute 53のAuto Naming 実は弊社大瀧が書いた、下記記事に有るように、Route 53のAuto Naming APIを利用したサービスディスカバリー実装の機能自体はありました。 Amazon Route 53 Auto Namingでサービスディスカバリを実現する ｜ Developers.IO 今回紹介する機能は、これをECSに拡張したものと言えます。 実際にECSサービスディスカバリーを設定してみる 前置きが長くなりましたが、実際にECSに登録する様子を見てみましょう。既に、既存のECSクラスターとタスク定義がある前提で解説していきます。 従来どおり、ECSのサービスを作成していきます。今回は起動タイプもFARGATE
NEW:サービスディスカバリのためのAWS Cloud Mapとのアプリケーション統合 | Amazon Web Services
Amazon Web Services ブログ NEW:サービスディスカバリのためのAWS Cloud Mapとのアプリケーション統合 By: Alexandr Moroz, Sr. Product Manager, Amazon Route 53; Madhuri Peri, Sr. IoT Architect, AWS Professional Services; Aaron Molitor, Sr. Infrastructure Architect, AWS Professional Services; and Sarma Palli, Sr. DevOps Architect, AWS Professional Services AWS Cloud Mapを利用するとクラウドをマッピングすることができます。Amazon S3のバケットやAmazon DynamoDBのテーブル、Am
CloudFormation で Amazon ECS サービス検出を利用する
簡単な説明 Amazon ECS コンソールを使用すると、サービスの作成中にサービス検出リソースを作成できます。ただし、CloudFormation の AWS::ECS::Service リソースタイプでは、サービス作成時にサービス検出リソースは作成されません。 注意: Amazon ECS コンソールでは、統合 API の CreatePrivateDnsNamespace、CreateService (AWS Cloud Map)、および CreateService (Amazon ECS) を使います。CloudFormation では統合を実装するために、単一の CloudFormation テンプレート内で AWS::ServiceDiscovery::PrivateDnsNamespace、AWS::ServiceDiscovery::Service、および AWS::ECS
Cloud MapでServerlessなリソースのサービスディスカバリを実装する – サーバーワークスエンジニアブログ
ちょっとお久しぶりの会社ブログ投稿な照井です。 今年は会期中の過ごし方や旅程を自分のペースで行きたかったのでre:Inventは個人的に参加してきました。とても楽しかったです。 tl;dr re:Inventでずっと欲しかったServerlessなリソースのディスカバリができるCloud Mapがリリースされたため、実証と実戦投入のための考察などしてみました。 結論から言うと「超便利。でも実戦投入するにはディスカバリ結果のキャッシュを上手く取り回す仕組みが必要だなー」って感じです。 Cloud Map https://aws.amazon.com/jp/cloud-map/ 何がやりたいか Cloud Mapは今までConsulやRoute53 APIとHealthCheckを駆使して自前で構築していたDNSベースのServiceDiscoveryがフルマネージドサービスでできる（Clou
re:Invent 2018 で発表されたAWS App Meshの仕組みを解説します | PSYENCE:MEDIA
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2018 の投稿記事です。 こんにちは。re:Invent2018 帰りの大島です。 去年はEKSで大いに盛り上がったre:Inventですが、2018年はApp MeshとCloud Mapの発表がコンテナ関連で注目を集めました。本記事では新しく発表されたApp Meshがどのような仕組みなのかを実際に動かしつつ、公式ドキュメントにも掲載されていない情報も含めて紹介します。 App Meshとは AWS App MeshはAWSで利用できるマネージドサービスメッシュです。Envoy proxyを使ってコンテナ化されたマイクロサービスの可視化やトラフィックコントロールを容易に出来るようになります。 AWS App Mesh is a service mesh based on the Envo
EnvoyとAmazon ECS Service Discoveryを利用したgRPCの負荷分散 – PSYENCE:MEDIA
EnvoyとAmazon ECS Service Discoveryを利用したgRPCの負荷分散 木村 勇太 2018.10.22 162 24126264 自己紹介 こんにちは。今年の7月からリクルートマーケティングパートナーズに入社した木村 勇太です。 私は現在開発支援G 1)エンジニアをサポートするエンジニア～RMP内製開発の強さ・魅力～ という。インフラや自動化など内製エンジニアへの開発支援を行うグループに属しています。 はじめに 弊社サービスの スタディサプリ ENGLISH ではアーキテクチャにMicroservices、gRPCを利用してサーバーサイドを構築しています。スタディサプリ ENGLISH のMicroservices化についての詳細は以下の記事にてご紹介しています。 スタディサプリENGLISH 大規模改修の裏側 – PSYENCE:MEDIA 今回、gRPCの負
マイクロサービス時代のSSOを実現する「Keycloak」とは
本連載では、近年注目されている認証プロトコル「OpenID Connect」をサポートするオープンソースのシングルサインオン（SSO）ソフトウェア「Keycloak」の活用方法を解説していきます。第1回目は、APIにおける認証／認可の仕組みとKeycloakの概要を紹介します。 連載目次 APIにおける認証／認可の仕組み 近年、金融や流通分野で注目されている「APIエコノミー」や「マイクロサービスアーキテクチャ」などの登場により、サービスの機能を「REST API」として提供することが当たり前になってきています。そして、REST APIを公開するためには、誰がアクセスしてきたのかを確認するための「認証（Authentication）」と、APIへのアクセスを誰に許可するのかという「認可（Authorization）」の仕組みが不可欠です。 しかし、複数のサービスがそれぞれ個別に認証／許可を
Sharing micro-service authentication using Nginx, Passport and Redis
Wikimedia Commons, Abgeschlossen 1, by Montillona And we are back with the regularly scheduled programming, and I didn’t talk about micro-services in a while. Here is what is occupying my days now – securing a micro-service system. Breaking down a monolith into a collection of micro-services has some wonderful properties, but also some nasty side-effects. One of them is authentication. The key pro
Memz One - Hierarchical Notepad
We cannot solve all problems for you, but here is how we can help Reduce stress by writing your problems downTurn them into actionable tasksKeep track of your progressAll your notes always at your fingertipsBoost your productivityLearn More Hierarchy supportOrganise your notes in unlimited hierarchy Sync and access anywhereUse our fast and reliable Cloud Service to sync your notes across your devi
Kong を使った Microservices Architecture API Gateway Pattern の実現方法 - Qiita
Kong を使った Microservices Architecture API Gateway Pattern の実現方法Dockermicroservices この記事は、Kong - API Gateway Pattern速習会＠Wantedlyの資料として作られたものです。 サービスが大きくなるとやりたくなってくること より高速な実装に置き換えたい APIを複数のサービスに分けて開発したい マイクロサービス化 何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界 「明確な」境界が必要 名前空間やスコープなど、プログラミング言語でも使用してい
APIアグリゲータのKongでマイクロサービスを統合管理する | DevelopersIO
ども、大瀧です。 「これからのWeb開発はマイクロサービスアーキテクチャだ！」とそこかしこで言われる昨今ですが、実際にマイクロサービスでAPIサーバーを実装しようとすると面倒な部分がいろいろ出てきます。例えば以下のような。 サービス毎にAPIが異なっていて統一性が無い サービス毎に認証機構を実装するのがつらい サービス毎にログの形式が異なる、アクセスログが残らないものがある DoS攻撃が来たらどうしよう これらWeb APIサービスに求められる課題をまとめて解決してくれるのが、APIアグリゲータです。(下図はAPIアグリゲータなしとAPIアグリゲータとしてKongを用いる場合) Kongとは Kongは、商用APIアグリゲータのMashapeのOSS版としてGitHubで開発が進めらているAPIアグリゲータです。 Kong - Open-Source API and Microservic
マイクロサービスで調査しやすいログをつくる - Qiita
マイクロサービスの開発を1から一人で作った話。 サービス要件や、全体のシステム構成、開発フローのおおまかな流れは、以下の記事にまとめた。 一からマイクロサービスの開発フローを作った話 ここでは各論を書く。 まずは本番でのログについて。 ログの重要度付けと、それぞれの保存場所 まずログの重要度と、利用方法から保存場所を考える。 今回は以下のとおりとした。 状態監視をするためのもの 関連する各サーバのログを、 ログ集約サーバで閲覧できるようにすること。 そのときだけ見れればよいログ。 もしかしたらあとから確認することになるかもしれないもの 非常事態に確認するかもしれないログ。 重要度に応じて、保存する期間を決めておく。 今回はgzip化したものを、S3にアップロードする。 サービス管理者以外も利用するもの たとえばデータの集計で利用するもの。 また、本サービスを利用するサービスがバグなどの調査
バッチ処理を再考する - 急がば回れ、選ぶなら近道
最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、本人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと？なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
