こんにちは！スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です
3-shake にはSreake共有会 という毎週、火曜日と木曜日に担当者が現場で得た知見などを発表する社内勉強会が開催されています。こちらのブログはそれらを変更修正しております。 syu-m-5151.hatenablog.com 元々しようとしていたの話 Go 1.18 の最新情報←Generics の深い話とかはもう既出すぎて気になる人は読んでる Go でのTDD(が実は20周年なので)←書いてる途中で自分が言うべきことなんてないことに気付く 今後、案件で増えるであろう gRPC についてインフラエンジニアが知っておいても良いと思ったという話 ← 今ここ TL;DR protobuf (Protocol Buffers) はデータフォーマットで、JSONの役割を置き換えるものです。一方 gRPC は通信プロトコルで、HTTPの役割を置き換えるものです。 gRPC をライブラリやツール
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
In this blogpost we’ll talk about the old Nginx-based traffic infrastructure, its pain points, and the benefits we gained by migrating to Envoy. We’ll compare Nginx to Envoy across many software engineering and operational dimensions. We’ll also briefly touch on the migration process, its current state, and some of the problems encountered on the way. When we moved most of Dropbox traffic to Envoy
Kubernetes Meetup Tokyo #40 https://k8sjp.connpass.com/event/206303/
Infra Study 2nd #4「セキュリティエンジニアリングの世界」 https://forkwell.connpass.com/event/219136/
広告技術部のUT@mocyutoです。 大幅コスト削減シリーズ第二弾です。 前回はこちら tech.gunosy.io 今回はアベイラビリティゾーン（AZ）間通信のコストをIstioのlocality load balancingを使って削減した話になります。 概要 Istioとは どのようにコスト削減したか まとめ 概要 みなさんはマイクロサービスを導入しているでしょうか？ 最近はモジュラモノリスが流行り始めている雰囲気を感じてきていますが、弊社の広告配信サーバは以下のようなマイクロサービス化された設計（と言っても2つのサービスしかないのですが）になっています。 構成図 一般的にクラウドプロバイダ上で構築している場合、耐障害性を高めるために複数AZ、複数リージョンに分散させることが基本になるかと思います。 弊社では、単一リージョン複数AZに分散させて稼働しています。 リージョン間の通信に
クラウドストレージサービスを提供するDropboxは、自社トラフィック制御基盤をNGINXからEnvoy Proxyへと移行しました。なぜNGINXからEnvoyへと移行したのか、その理由や問題点などについて、Dropboxがブログ上で公開しています。 How we migrated Dropbox from Nginx to Envoy - Dropbox https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy NGINXはDropboxのトラフィック制御基盤として過去10年ほど問題なく稼働していましたが、サービス間通信のREST APIからgRPCへの移行、Bazelによるビルド管理など、モダンなシステム導入が進むにつれて、Dropboxのアプリケーションデプロイに関するベストプラク
はじめに こんにちは、計測プラットフォーム部バックエンドチームの高木（@TAKAyuki_atkwsk）です。ZOZOMATシステムではAPIのリバースプロキシとしてEnvoyおよび付随するgRPC-JSON transcoderを導入しています。これらによって依存するサービスにレガシーなサーバーが存在していても部分的にgRPCを採用しモダンなアーキテクチャを広めようとしていることについて紹介します。 なお、本記事は以下記事のシリーズとなっておりますので合わせてご覧いただけるとZOZOSUITやZOZOMATなど計測プラットフォーム部の取り組みについてより深くご理解頂けるかと思います。 techblog.zozo.com ZOZOMATシステムとEnvoyについて ZOZOMATシステム構成におけるEnvoyの役割について簡単に説明しておきます。クライアント（ZOZOTOWNアプリ等）とZ
この記事は、NTT Communications Advent Calendar 2021 4日目の記事です。 こんにちは、イノベーションセンターでSREとして働いている昔農(@TAR_O_RIN)です。主にNTT Comのソフトウェアライフサイクルの改善への取り組みやアーキテクトに関わる仕事をしております。本日はサービスメッシュを題材に，その中で用いられるEnvoyの活用パターンを手を動かして理解するお話をさせていただきます。 また，昨年までのアドベントカレンダー記事もご興味があればご覧ください！ 2020年 How do you like k3s ? - CoreDNSで作るお家DNS Cacheコンテナ 2019年 TektonでCI/CDパイプラインを手の内化しよう 2018年 DevOpsってこんな仕事！考え方とスキルセットのまとめ 2017年 DockerのnetworkをCa
背景 こんにちは！Hanoi Dev Centerでバックエンドエンジニアをしているminhquangです。この記事では、私がAI事業本部のある新規プロダクト開発に参画した際に経験したパフォーマンスチューニングについて話したいと思います。 皆さんはサービスのローンチ(サービスを世の中に初めて出すリリース)をやったことがありますか。サービスローンチするときに、リクエストのスパイクや、ユーザー数の増加によるサーバー負荷増加など、様々な未知な課題が存在します。 私のチームでは数百万人の利用が見込まれるサービスにおいて、18000RPSを実現するべく負荷試験とパフォーマンスチューニングを実施しました。 本記事では、上記のサービス要件を満たすために私たちが取り組んだ負荷試験やパフォーマンスチューニングについて説明しつつ、これらの経験から得られた学びを共有したいと思います。 前提 技術スタック サーバ
こんにちは ハタ です 今回はインフラ/基盤開発で導入している Envoy について紹介したいなと思っています 現在ミラティブでは Go移行 を進めているところで、 既存のWebアプリケーション(Perl で実装されてます)と、新たに Go で実装された Web アプリケーションをシームレスに導入/切り替えするために Envoy の導入を行いました Envoy xDSとConsul によるインスタンス管理 NGINX や HAProxy または Apache HTTP Server など使い慣れた && ノウハウもあるミドルウェアではなくなぜ Envoy を選定したかというと、 なんといっても魅力的なのが xDS と呼ばれる Discovery Service 群があることで柔軟に既存コンポーネントと連携を取りやすいことやAPI操作によるコントロールの柔軟性が高いことが決め手となっています
おはようございます、もきゅりんです。 Shall we mesh ? 弊社コンサルティングには、今一度 AWS の各サービスを初心に返って、基本的な部分から見つめ直してみよう、解説してみようといったブログリレーという企画があるのですが、本稿はそれを模して、個人的な AWS App Mesh 再入門という体にしてみました。 どちらかというと、未来の自分のための備忘録と言えます。 これまで AWS App Mesh (以下 App Mesh) に入門されていなかった方も、すでに脱会されてしまった方も興味があれば再入門して下さい。 App Mesh とは何か サービス(アプリケーション)間の通信制御と可視性を実現するサービスメッシュを提供する AWS マネージドサービス です。 ブラックベルトにならってまとめると以下のような機能があります。 HTTP通信のリトライやタイムアウト 通信のトレーシン
マイクロソフト、サービスメッシュの新たなオープンソース実装「Open Service Mesh」発表。Envoy採用、CNCFへ寄贈予定 マイクロソフトは、Kubernetes対応のサービスメッシュ（Service Mesh）をオープンソースで実装するプロジェクト「Open Service Mesh」を発表しました。 We are beyond excited to introduce Open Service Mesh (OSM), a lightweight and extensible #servicemesh that implements @SMI_spec and runs on @kubernetesio @EnvoyProxy! Check out what we've been up to here:https://t.co/l6fy4OUorO — Open Servi
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Istioのサイドカーメッシュを題材にしたEnvoyの設定の抽象化について 様々なサービスメッシュツール (特に、Istio、Consul、Ciliumなど) でも流用できるEnvoyの知識について この記事から得られる知識 01. はじめに 02. 様々なリソースによるEnvoy設定の抽象化 サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 03. istio-proxyコンテナによるHTTPS処理 Istioコントロールプレーンの仕組み サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 04. EnvoyによるHTTPS処理 Envoyの設定の種類 フィルター フィルターの一覧 フィルターチェーンの仕組
This image includes the work that is distributed in the Apache License Version 2.0 株式会社Flatt Securityでセキュリティエンジニアとして働いている米内です。 本稿では、Envoy に独自メトリクスを追加するようなフィルタのサンプル実装の提示を通して、 WebAssembly によるサービスプロキシの拡張を可能にする仕様である Proxy-Wasm について紹介します。 Proxy-Wasm とは Proxy-Wasm の周辺 Rust による Envoy の拡張 SDK の利用 スタートアップ処理 メトリクスの定義 メトリクスの値の変更 動作例 おわりに Proxy-Wasm とは 近年は WebAssembly System Interface（WASI） を中心として、「WebAssembl
みなさん、プレビュー環境してますか？どうも、かたいなかです。 以前、記事や登壇でIstioベースのPreview環境の構築方法をご紹介しました。 made.livesense.co.jp 外向けに発表したものの、Istioの運用工数や学習コストがネックとなってしまい、実際の転職会議の開発環境の導入にはいたっていませんでした。 最近になってGateway APIの実装例も増えてきて、Istio以外にもプレビュー環境でのヘッダを元にしたルーティングの実現において、現実的な選択肢となりそうなツールが増えてきました。そこで、Gateway APIのEnvoyによる実装であるEnvoy Gatewayを用いて、サービスメッシュを使用しないプレビュー環境の構築を試してみたため、この記事では構成例をご紹介します。 なお、今回の記事の中ではプレビュー環境の説明等について前回の記事と同様の説明を再度する箇所
こんにちは、ミラティブのインフラを担当している清水です。 ミラティブではクラウドに Google Cloud を利用しているのですが、稀にインスタンスの性能劣化が発生し動かしているアプリケーションの応答時間が長くなることがあります。 非同期な処理の場合は一時的にタスクキューの時間あたりの処理数が減るものの、遅延を許容できる機能であれば時間経過で回復するのでシステムを継続稼働できます。 一方で、web サーバのように同期処理の場合はリクエストを時間内に返すことができずに timeout したりだとか、worker が埋まって新たにリクエストが返せなくなったりと、正常にリクエストを返すことができずにユーザのクライアントにエラーが返ってしまします。 そこで、今回はクラウドが不調になったときに web サーバへ流れるリクエストの流量を動的に制御し、一時的にリクエスト数を減らしてユーザのクライアント
この記事は @hatappi によって提供される Developer Productivity Engineering Camp blog series の１つです。 序論 私達 Microservices Network team の管理するコンポーネントの1つに Istio があります。 メルカリでは2017年から既存のシステムを Microservices におきかえるプロジェクトが始まり、Microservice の数は今も増え続けています。Microservice の数が増えるにつれて起きる問題に対処するために Service Mesh の実装の１つである Istio を私達は導入しました。 この記事ではどのような問題があり、それを Istio がどのように解決するのかを紹介します。 Microservice Architecture におけるネットワークの課題 Microser
概要 Envoyのyamlは非常に長大で初めて読む人からするととても分かりにくいです。 しかし実際は各要素の役割を理解するととてもシンプルに構成されていることが分かります。 そのための手助けとしてこちらで図を交えながら説明します。 環境 Envoy 1.22.0 要素の説明 まずは各要素を理解します。 downstreamとupstream 要素 説明 downstream Envoyからみたクライアント upstream Envoyがサービスに対するリクエストを転送する際に接続するエンドポイント（ネットワークノード） よくあるパターンで図示してみると以下です。 front proxyモデル sidecarで外部からリクエストを受ける sidecarでローカルアプリケーションからのリクエストを転送する このようにsidecarモデルのローカルアプリケーションは、downstreamにもup
@ Infra Study Meetup #8 「インフラと研究開発」 https://forkwell.connpass.com/event/193256/
表を見ていただくと分かるように今回の変更によって Istio 1.10 以降は Istio なしの場合と挙動も変わらないため、認知負荷も減り今までよりも Istio を採用しやくなったのではないでしょうか。 ここまで Istio 1.10 から変更になった Inbound Fowarding の内容を見てきました。 次にこの変更によって私達のサービスに起きた問題を共有していきます。 起きた問題 今回の変更によってアプリケーションが動かなくなるケースとしては、アプリケーションが lo にのみ bind している場合です。 Istio ではこれを事前にチェックするためのコマンドを用意しており istioctl experimental precheck を実行します。 該当する Pod がある場合には IST0143 という message code が出力されます。 該当する Pod があっ
Google Cloudで実践！ クラウドネイティブな開発 サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める 本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第6回では、サービスメッシュについて紹介します。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。 マイクロサービスアーキテクチャの課題 これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、
LINEが定期的に開催する、Kotlinをテーマにした技術者向けのミートアップ「LINE Developer Meetup for Kotlin」。ここで、開発3センターの岩谷氏が登壇。「LIVEBUY」の開発でKotlin Coroutineを利用した知見を紹介します。 自己紹介とセッションの概要 岩谷明氏：みなさんこんにちは。LINEの岩谷と申します。LINE Developers Meetup for Kotlinにご参加いただき、誠にありがとうございます。本日最初のセッションですが、「LINEでKotlinを活用してサービスを作っていく話」と題して、発表します。よろしくお願いいたします。 簡単に自己紹介します。私は2016年にLINE株式会社に入社しました。今までは「LINE LIVE」や「LINEノベル」などのiOSやAndroidのエンジニアをしていましたが、2019年から、本
[アップデート] AWS App Meshが「仮想ゲートウェイ」を使ったメッシュ外部からのIngressアクセスをサポートしました みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 AWSが提供するメッシュサービス AWS App Mesh において、新しい機能「仮想ゲートウェイ」(Virtual Gateway) がリリースされました。 AWS App Mesh launches ingress support with virtual gateways これは「App Meshの使い方が大きく広がるんじゃないか？」と思える、結構ビッグなアップデートではないかと思います。 AWSブログでハンズオンも公開されていますので、こちらに沿って試してみたいと思います。 Introducing Ingress support in AWS App Mesh | Containers
Life of a Request Below we describe the events in the life of a request passing through an Envoy proxy. We first describe how Envoy fits into the request path for a request and then the internal events that take place following the arrival of a request at the Envoy proxy from downstream. We follow the request until the corresponding dispatch upstream and the response path. Terminology Envoy uses
こんにちは、スタディサプリENGLISH SREグループの横山です。 以前の記事1) スタディサプリENGLISHの基盤をECSからEKSに移行しましたにあるように、先日ついにスタディサプリENGLISHのインフラ基盤をECSからEKSに移行することができました。 本記事では、このEKS移行に伴いAWS App Mesh(以下、AppMesh)の導入をしたので、これに関連した話を書いていきたいと思います。 なぜAppMesh導入を検討し始めたか インフラ基盤がECSだった頃、gRPCの負荷分散にEnvoyとAmazon ECS Service Discoveryを利用していました。この構成については以下の記事に詳細があります。 EnvoyとAmazon ECS Service Discoveryを利用したgRPCの負荷分散 この構成にした当初は、デプロイ時にECS Serviceのローリン
はじめに NRI OpenStandia Advent Calendar 2020の19日目は、最近DropboxがNginxから移行したことでも話題になったEnvoy Proxyについて、これから利用したい方や学んでいきたい方に向けて、そもそもどんなものなのかを紹介していきたいと思います。 Envoyとは EnvoyはNginxと似た機能を持つOSSで、マイクロサービスに対応するため、サービス間のネットワーク制御をライブラリとしてではなく、ネットワークプロキシとして提供することを目的に開発されました。 これにより個々のサービスはEnvoyを経由してそれぞれのサービスへ接続します。これはネットワークを抽象化して、アプリケーション開発者をビジネスロジックに集中できるようにするという目標のために行われています。 例えば、Envoyを利用したアーキテクチャでは、アプリケーションと同じホスト上にE
背景 マイクロサービス環境でIstio(Envoy sidecar)を使っていると、いくつかのエラーに遭遇します。 それぞれどういった状況で発生しているエラーなのかを区別できないと、適切な対応にならないため各種エラーをまとめます。 環境 Envoy 1.22.0 Go 1.21 構成 次のようにclient appやserver appにsidecarが挟まるようにします。 エラー dial tcp 172.20.0.4:8001: connect: connection refused connection error: desc = "transport: Error while dialing: dial tcp 172.20.0.4:8001: connect: connection refused が発生するパターンです。 周辺ログも含めると次のようになります。 timeout-
Istioのインストール、サイドカープロキシ（Envoy）の挿入、マイクロサービスの可視化：Cloud Nativeチートシート（10） Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Istioの環境構築と実践ポイントを説明します。
この記事は新野淳一氏のブログ「Publickey」に掲載された「マイクロソフト、コンテナをサーバレスで実行する「Azure Container Apps」発表。KEDAとDaprを採用。Ignite 2021」（2021年11月4日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。 Azure Container Appsは、コンテナとしてパッケージングされたアプリケーションを、何らかのイベントをトリガーにして実行します。アプリケーションは負荷に応じてスケールし、イベントがなくなればインスタンス数はゼロになる、いわゆるサーバレスな実行環境を実現するサービスです。 下記は「Introducing Azure Container Apps: a serverless container service for running modern apps at scale」から
Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWS App Mesh 資料及び QA 公開 先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか？それとも、ある程度の規模になってから導入するべきでしょうか？ A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、
この記事はさくらインターネット Advent Calendar 2020 5 日目の記事です。 https://qiita.com/advent-calendar/2020/sakura 現在社内にて Nomad と Consul を利用してサービス開発を行っています。 Nomad はアプリケーションのスケジューリングを行い、ざっくりと Kubernetes,Marathon 等と同様の機能を提供しています。 Consul はサービスの死活監視・サービス検出・サービスメッシュ等を提供しています。 このような構成では、外部からの通信を適切にアプリケーションへ転送するゲートウェイが必要となります。 Nomad+Consul を利用している環境の多くは、consul-template で Nginx の設定を自動生成し、変更があった際には reload を行うという構成を採用しているかと思います
メインコンテナの起動前に istio-proxy の起動を完了させるIstio の Sidecar は他のコンテナよりも先に起動してくれないと通信に影響がでてしまうため、確実に先に起動させるための設定を紹介 Istio 1.7 で追加された機能2020年8月21日に Istio 1.7 がリリースされました。その RELEASE NOTE の Production operability improvements 項に次の節を見つけました。 You can delay the application start until after the sidecar is started. This increases the reliability for deployments where the application needs to access resources via its pr
proxy-wasm-rust-sdk?proxy-wasm-sdk-rushはWebAssembly for ProxiesというApplication Binary Interface(以降ABIと表記)に従って実装されているライブラリです。 予め提供されているtraitに実装を追加していくことで簡単にwasm-filterを作成できます。 proxy-wasm-rust-sdkの使い方早速、wasm-filterを作っていきましょう。 作り方は大まかに以下の3つのstepになります。 cargo.tomlのdependenciesに proxy-wasm を追加lib.rsに_start()を作成任意のcontextの実装を作成それぞれの手順について少しだけ丁寧に見ていきます。 cargo.tomlのdependenciesに proxy-wasm を追加 [dependencies
Envoy情報 Envoyとは 主な機能 主な特徴 ユースケース 動作環境 Envoyのライセンス 参考情報 オープンソース年間サポートサービス Envoyとは Envoy（エンヴォイ）はクラウドネイティブなWebサービスのために設計されたL4/L7両機能を持つ高機能なプロキシソフトウェアです。 Envoyは、急速に普及したマイクロサービスの分散システム構築・運用を安定させるため2015年5月にライドシェアサービスのLyftが開発を始めました。 Envoyは、C++で実装されており、開発はAmazonやTwitterにも在籍したことがあり、10年以上分散システムに携わってきた配管工(Plumber)ことMatt Klein(マットクライン)氏を中心に行われました。 2016年9月にはEnvoy 1.0をオープンソースとしてリリースされ、2017年9月にはIncubatingプロジェクトとし
はじめまして、2023/6からfreeeのEnabling SREチームに所属している大木竜勝(ryu)です。 この記事はfreee Developers Advent Calendar 2023 - Adventar 3日目です。 この記事ではenvoyの分散トレーシングを用いてオブザーバビリティの向上を実現した取り組みについての記事になります。 背景 freeeではAmazon Web Services (AWS) Elastic Kuerbentes Service (EKS) クラスタ上にアプリケーションが載っておりその構成としてはenvoyが前段に存在し、後段に各アプリケーションPodが存在する構成となっています。 freeeにおける基本的なPod構成 上記の構成においてクラスタの単位はfreee会計やfreee人事労務といったプロダクト毎にクラスタが分かれている構成となっていま
こんにちは、ユーザベースのProductチームでSREをやっています阿南です。弊社ではKubebrnetes + Istioを利用してサービスメッシュの構築、マイクロサービスの運用を行っています。Istioでは sidecar proxyとしてEnvoyが利用されていますが、このEnvoyをFront Proxyとしても利用できないかと思い、よく使われる設定について調べてみました。下記目次です。 EnvoyをFront Proxyとして利用するメリット Envoyのバージョン Front ProxyのためのEnvoy Configuration 80(HTTP),443(HTTPS)でアクセスを受け付ける Pathベースのルーティングを設定する レスポンスに特定のヘッダーを付与する Healthcheckに失敗した場合、upstreamの対象から除外する Cookieをもとに、upstre
Tetrate & Bloomberg Announce the First Release of Envoy AI Gateway Learn more › close
Slack has a global customer base, with millions of simultaneously connected users at peak times. Most of the communication between users involves sending lots of tiny messages to each other. For much of Slack’s history, we’ve used HAProxy as a load balancer for all incoming traffic. Today, we’ll talk about problems we faced with HAProxy, how we solved them with Envoy Proxy, the steps involved in t
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く