GitHub - elastic/cloud-on-k8s: Elastic Cloud on KubernetesYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Elastic Cloudへプライベート接続を試してみた #elastic #AWS - クリエーションライン株式会社
※投稿時点における最新版を採用しています。 【構成図】 前提 AWSリージョンおよびElastic CloudのDeployment構成はコスト観点で選択しています。 VPCとサブネットは、AWSアカウント作成時のデフォルトVPCを利用しています。 Elastic Cloud環境は、接続するAWSのVPC環境と同じリージョン(今回は、us-west-2)にしておく必要があります。 Elastic CloudとAWS VPCはAWSサービスのPrivateLink(インターフェースVPCエンドポイント)を利用します。 VPC側からElastic Cloudにアクセスするには、VPCエンドポイントのDNS名をRoute53のプライベートホストゾーンにCNAME登録する必要があります。(VPCエンドポイントのDNS名ではAPIがはじかれます) 【参考】 ・インターフェイス VPCエンドポイント
物流支援サービスを支えるAWSサーバーレスアーキテクチャ戦略 - ZOZO TECH BLOG
はじめに こんにちは。SRE部BtoBチームの蔭山です。Fulfillment by ZOZO（以下FBZ）で提供しているAPIシステムの運用及び監視を担当しております。 FBZではAWS Lambdaを主軸としてAWSが提供しているフルマネージドサービスのみを利用するサーバーレスアーキテクチャを採用し、構築・運用してきました。今回は実際にどのようにサーバーレスアーキテクチャを活用してサービスを構築・運用・監視しているかご紹介します。 これからサーバーレスアーキテクチャを活用してサービスを構築されようとしている方の参考になれば幸いです。 なぜサーバーレスを採用したのか FBZはZOZOTOWNとブランド様が運営されている自社ECサイト間でリアルタイムに在庫情報を連携し、ZOZOTOWNと自社ECサイトでの在庫の一元管理を実現するAPIサービスです。そのため、マスタであるZOZOTOWNの在
Splunkのアクセスログ解析でWEARのAPIを201件(約5万行)削除した話 - ZOZO TECH BLOG
こんにちは、WEAR部運用改善チームの佐野です。 私たちのチームでは、WEARの日々の運用業務を安全かつ効率的に行えるよう改善をしています。今回は、年初から行っていた不要APIの削除作業についてご紹介します。 背景 残念なことに長い間WEARでは不要になったAPIが放置されてしまっており、どのAPIが実際に使用されているものなのかが分かりにくい状態になっていました。WEARのAPIはWeb・iOS/Androidアプリ・バッチ・社内ツールから参照されているのですが、使用されているのかが明確でないAPIが多数残されていることにより、以下のような問題がありました。 リプレイスや脆弱性診断の対象箇所の洗い出しの際に余計なコストが掛かる 運用業務において何かを調査をする際に、使用されていないAPIがあることで不要なコードも増え、調査がしにくい 実際に、他部署からの問い合わせの調査でとある処理を追っ
GitHubのソースコードがGitHub上にリークされる、公開した人物は「GitHubのCEO」を偽装
ソフトウェア開発プラットフォーム「GitHub」のソースコードが、GitHubのナット・フリードマンCEOを名乗る人物によってリークされました。このリークを機に「これまでクローズドソースだったGitHubをオープンソースにすべき」という意見が強まっています。 GitHub Source Code Leak https://resynth1943.net/articles/github-source-code-leak/ GitHub Source Code Leak | Hacker News https://news.ycombinator.com/item?id=24994746 今ではオープンソースコミュニティに欠かせない存在となっているGitHubですが、GitHubそのもののソースコードはクローズドソースとなっており、リリースから明らかにされることはありませんでした。しかし、20
Kubernetes 1.18 で kubectl alpha debug を使って Pod をデバッグする - Qiita
はじめに この記事は、先日リリースされた Kubernetes 1.18 1 でエフェメラルコンテナ関連機能の実装がほぼ完了して、デバッグ目的のエフェメラルコンテナ 2 を作成する kubectl alpha debug コマンドが追加されたということで、これらを使って Pod をデバッグするまでの流れをまとめたものとなります。 エフェメラルコンテナ? kubectl debug コマンドってそもそもなんだ? となった方は Kubernetes 1.18: SIG-CLI の変更内容 で詳細に解説されていますので、まずはそちらを一読するのが良いかと思います。 それでは実際にやっていきます。 エフェメラルコンテナ機能を有効にしたクラスタ作成 Feature Gates で EphemeralContainers を指定してエフェメラルコンテナ機能を有効にして Kubernetes 1.18
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
