そるでぶろぐ

こんにちは。ソリューション開発部の桑原です。 先日、社内LT大会を開催いたしましたので、開催に至る経緯や当日の様子を紹介いたします。LT：Lightning Talksの略で、短ければ3分、長くても10分程度で終わる短いプレゼンのこと。ゆるゆるな雰囲気のなか行われることが多いです。きっかけ 社員どうしで熱く語りたいんだ 弊社社員には [blogcard url="https://twitter.com/arksystemsJp/status/1004655406306725888"] に紹介されるような技術的に優れた社員や、技術はもちろんのこと技術以外の方面に対しても勉強を続けている社員が多数在籍しています。しかし、普段はプロジェクト単位での働き方となるため、他のプロジェクトにアサイン中の社員が何に興味を持ち、どのようなことを勉強しているか、などが、どうしても見えにくくなってきます。 元々情報共有には積極的な会社ではありますが、忙しさが続くと、ついつい疎かになりがちです・・・ でも、他の社員が勉強していることって気になりますし、自分が勉強していることって他の社員にも伝えたいこともありますよね。 せっかく同じ会社にいるのだから、配属先プロジェクト、好きな言語や得意な技術分野などの垣根を取っ払い、何かしらのテーマについて社員どうしで熱く語るための機会がほしかったです。 深く議論することで自分の持ち得なかった視点や思考に触れることができ、広い視野や深い思考を手に入れるための良い機会になりますよね。 そうだ社内LT大会だ LT大会であれば時間も短いため登壇ハードルが低いうえ、数多くの社員の話を聞くことができそうです。 社内だからこそ自信がなくても登壇しやすかったり、聞きにくいような質問や他の人とは異なる意見をだすことのハードルが低い、などのメリットもありますね。 そういった思いから社内LT大会の実施をすることになりました。 企画から当日実施まで 企画 告知・準備 開催2ヶ月前に一度、部内で軽く告知をし、その後1ヶ月前に登壇者と聴講者の募集を全社に対して行いました。 他部署からも登壇者としての参加表明もありました。別の部署の社員から技術話を聞けるのはそうそうない機会だったのでとてもありがたかったです。 また、飲食つきの緩い雰囲気で社内LT大会をしたかったため、会社に“スポンサー”を依頼したところあっさり「OK」をいただきました。素敵な会社です。 実施 セッション内容は以下のようになりました。 登壇者が9名で、技術・非技術入り乱れているあたりは社内LTならではと感じますね。 タイトル 区分EAのDDLテンプレート機能を使って人生をリッチにしよう ツールハックメンタルケアについて マネジメントAIについて 技術MVにゃんちゃら 技術ふりかえりをしよう チーミングコンテナネイティブの時代 技術Microsoft :The Future Computedから読む未来の働き方 働き方改革Excelのショートカットを使いこなそう ツールハックAWS CodeDeployについて 技術  発表時間が5～10分で、質問含め一人あたりの持ち時間を15分とLTにしては長めの時間配分を設定してましたが、それでもギリギリだったかな。という感触でした。 ひょんなことで意見の違いが出ると、どこまでも深く議論出来てしまうので、発表内容に対する議論の時間をしっかりとっても面白いのかな。と思いました。 特にMVにゃんちゃらではバリデーションの置き場所に関して、あるべき論と現実論で休憩時間を過ぎても白熱した議論が続いていたのが印象的でした。エンジニア心をくすぐられる内容ですね。 やっぱりといいますか、議論が好きな社員が多いようです。ホワイトボードを使ってまとめもしてLT大会自体への振り返りもできました。 KeepもProblemとそれに対するTryもしっかり出てきたので、今後よりよいLT大会の運営ができそうです。 振り返り 社内LTの意義 今回の発端となった社員同士の情報共有はもちろんですが、 外部でのLT大会以上に間違いを恐れずに発信・質問ができることや、外部で発表するほどではないけど、なんとく発表したい。みたいな温度感で登壇できるのはやはり社内LT大会ならではだな、と感じました。 感想 企画時点では、忙しくて登壇者が集まらなかったら…、聴講者が来なければ…、盛り上がらなかったら…、などの不安はもちろんありましたが、まずはやってみるものですね。 チャレンジと失敗に寛大な文化にも後押しされた気がします。 また、「楽しかった」「またやるべき、やりたい」という意見を参加者からいただけたことが大変嬉しく励みになります。 今回のLT大会を単に楽しかった。で終わらせずに次、そのまた次のLT大会へと続けると同時に、LT大会以外でも情報共有がもっとしやすい、より良い土壌を作っていけたらなと考えております。

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます！【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展！ 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編 【わたしに♥おまかせ Zabbix 号外】Interop

プラットフォーム技術部　山本です。 「自社システム運用のレベルはどうなのか？」「漠然と課題感はあり現場は困っているが、経営層に改善の必要性をうまく訴求できない」などなど企業のIT管理部門が抱えるお悩みに応え、弊社の豊富なシステム運用の実績をベースに第三者的な評価サービスを実施してきました。 今回は最近の事例に沿って弊社の「運用アセスメント」サービスについてご紹介いたします。 IT部門が抱える課題、ニーズ IT部門でも特に「システム基盤に関わる各種企画やイベント対応」が山積している中で「日々の運用保守業務」も回さなければならない、予算も少なく体制も拡充しにくい「インフラ担当部署」は悩みが多いと思います。実際そういった悩みを抱え自助努力ではにっちもさっちもいかなくなったお客様からご相談をいただくケースがほとんどです。システム運用管理がしっかり回っていない、そもそも枠組みが整備できていない 個人のスキルに依存 業務負荷の集中、慢性的な高負荷 課題対策や改善が遅々として進まない 要員とスキル不足が深刻でベンダーコントロール、プロジェクトマネジメントに手が回らない。結果、品質が悪くトラブルが頻発。。。と悪循環が止まらない運用アセスメントサービスとは？ 表示されている画像の文字が小さくて読みづらい場合は、画像上にて右クリックをしていただき、新しいタブやウィンドウで表示いただくことによって、読みやすい大きさで表示することができます。 弊社運用アセスメントの標準的な評価対象は下記6領域となります。 システム運用保守の評価と改善策検討および改善実行計画の策定までを以下のステップで実施します。  ASIS分析 このステップでは、各種資料確認や数回の現場担当者ヒアリング及び過去障害対応履歴の確認結果から課題を抽出します。 以下は実際のアウトプットサンプル(一部抜粋)になります。抽出した課題から簡潔に総評を纏めました。TOBE検討 このステップでは、ASIS分析ステップで抽出した各課題への対策方針と期待効果及び必要コスト概算を検討しました。 以下は実際のアウトプットサンプル(一部抜粋)になります。 赤枠内が本ステップでの追記内容(優先度､対策方針､難易度､効果､効果目安､必要コスト概算)となります。  各対策の優先度と前後関係を踏まえて全体の関係を図示し、直近実施するスコープをお客様と協議･合意し、まずは優先度高の対策について具体的な実行計画を策定することになりました。  改善策の実行計画策定 優先度の高い対応策について具体的な実行計画を策定しました。 以下は実際のアウトプットサンプル(一部抜粋)になります。 「目的」「目標」「実施イメージ」「スケジュールとWBS」「必要なHW､SWなど」「成果物」「期待効果」の章立てで纏めました。実際にこのお客様では引き続き改善実行フェーズのご支援に繋がり、 これから順次改善をお客様と共に進めていきます。 その他実績 これまで実施してきました運用アセスメント及び改善支援の実績をいくつかご紹介いたします。 駐車場 2005～2009年 アセス後に改善支援を約3年に渡って実施。 各種運用改善から始まり､システム更改プロジェクトなどイベント案件のPM支援から技術支援までお客様の課題･ニーズに柔軟に対応。 物流 2008～2012年 アセス後に改善支援を約3年に渡って実施。 監視基盤構築や基幹業務システムの仮想環境集約移行支援など多数イベント案件対応や運用改善支援などお客様の課題･ニーズに柔軟に対応。 金融 2011～2014年 アセス後に改善支援を約2年半に渡って実施。 基幹業務システムのセンター集約＋仮想環境移行のPM支援や各種セキュリティ対策支援などお客様の課題･ニーズに柔軟に対応。 最後に 弊社は下記の基本スタンスに基づき、「お客様のそばで、お客様のためのITを」をモットーに真にお客様に貢献するサービスを提供いたします。お客様が抱える課題の解決を第一に考え、壁を設けず最大限可能な支援を ベンダー製品・サービスに縛られることなく、中立的に解決策を考え、お客様に解かりやすく示します 弊社リレーション有無にかかわらず、フラットに最適なソリューションを持つベンダー、SIerを巻き込み目的指向で解決策を検討します お客様の「費用感」「達成レベル感」「スピード感」「優先順位」を適切に把握し、柔軟かつバランスのよい現実的な解決策を提案します アセスメントやコンサルに終わらず、実効性の高い解決策から具体的な計画に落とし、お客様との確実な合意形成のもと責任をもって結果を出します「運用アセスメント」に限らず、お困りの際はお気軽にご相談ください。

プラットフォーム技術部の佐藤です。 だいぶ前の話になりますが、CentOS7/RHEL7のSELinuxポリシーのバグフィックスで、tomcatプロセスを制限のあるプロセス(confined)として動作させられるようになりました。 以前は制限のないプロセス(unconfined)の状態で、実質SELinuxのアクセス制御を受けない状態でした。 Firewallのルールに例えると、制限なし(unconfined)は最後のルールがallow all、制限あり(confined)は最後のルールがdeny allな状態です。RHBA-2017:1861 - Bug Fix Advisory Bug 1432083 – tomcat_t domain is in unconfined_domainただ、実はこのバグフィックスだけではtomcatサービスが起動できない状態になってしまうので、そのまま適用するためには次のバグフィックスまで待つ必要がありました。RHBA-2018:0763 - Bug Fix Advisory Bug 1470735 –

こんにちは。AWSを触り始めて約半年、入社2年目。プラットフォーム技術部の大畑です。 先日、CentOS 5.11環境でAWS CLIを使う機会があったのですが、主な導入方法として公式で紹介されているpipではインストールすることが出来ず、導入前から若干ハマるという事件が起こりました。 CentOSと言えば、2018年5月現在の最新バージョンは7系ですが、場合によっては古いOSを使い続けなければならないこともあるかと思います。 そこで本記事では、CentOS 5.11におけるAWS CLIの導入方法についてまとめてみたいと思います。※CentOS 5系のサポート期限は2017年3月31日で切れています。 　今から導入する人はくれぐれも化石バージョンを選ばないようにしましょう。 環境・制約条件CentOS 5.11 なるべく現行システムに変更を加えない 最低限のツールのみをインストールする導入方法 Python 2.6の導入 AWS CLIをインストールするために必要な要件は以下となります。Python 2 バージョン 2.6.5+ または Python 3 バージョン 3.3+ Windows、Linux, macOS, or UnixCentOS

本連載では、JWA公認 Webアナリスト検定を受けてみたい！という人向けに、私が勉強したことをベースに解説を簡単にまとめ、不定期に公開したいと思います。【受けてみた】JWA公認 Webアナリスト検定 【Webアナリスト①】Webアナリストのお仕事 【Webアナリスト②】Webサイトのボトルネックを特定する 【Webアナリスト③】Webサイトへ集客を行う方法 【Webアナリスト④】集客に関する指標の用語や計算式のまとめ 【Webアナリスト⑤】Webサイトへの流入 【Webアナリスト⑥】Webサイトでの回遊（本記事）こんにちは。ソリューション開発部 情報発信分科会の佐々木です。 今回はWebサイトでの回遊について解説します。 回遊とは、「ユーザーがWebサイトやページ内のコンテンツを見て回ること」を指します。回遊の分析においては、サイトを訪れたユーザーが目的の情報に辿りついているかに着目することが大切です。 流入の分析とサイトの改善 入口ページの分析と改善 ユーザーがサイトの入口となるページだけを見て帰ってしまった数を直帰数、サイトの閲覧を開始したセッションの総数のうち最初の1ページ目だけを見て帰ったセッションの割合を直帰率といいます。入口ページを分析する際は、まずサイトの直帰率を確認するところから始めます。 閲覧開始数が多く、直帰数・直帰率の高いページがある場合、ページに基本的な欠陥（読み込みに時間がかかりすぎる、ユーザーが知りたい情報がどこにあるかわからない等）がある可能性が高いです。ユーザー目線でページを訪問して検証を行い、ページの欠陥を優先的に修正していきます。 また、流入数が少なく直帰数・直帰率が低いページがある場合にはSEOやリスティングなどによって流入数を増やす施策を行います。 流入数が少なく直帰数・直帰率が高いページについては、直帰数を減らす施策を行ったとしても流入数が少ないため改善のインパクトが低いと考えられます。そのため、改善の施策を行うかどうか検討する必要があります。 サイト内の経路分析と回遊の改善 入口ページの分析の次は、サイト内の経路分析を行います。 ユーザーがサイト内をどのように回遊して、どこから離脱したかを確認し、ユーザーが想定していたシナリオ通りにサイト内を進んでいるか、迷っている遷移はないかなどを分析していきます。 離脱とは 次のページを読み込むまでをページ滞在時間、サイト内でユーザーが閲覧した最後のページ（離脱ページ）を読み込むまでをサイト滞在時間といいます。なお、ユーザーが入口ページから直帰してしまった場合はページ滞在時間もサイト滞在時間もわかりません。サイトを閲覧中にユーザーが別サイトに飛んだ場合でも、セッションが切れていなければ（別サイトに飛んでから戻ってくるまでの間が30分未満であれば）サイトの滞在時間も継続されます。また、別サイトに飛んでいなかったとしても、1つのページに30分以上滞在するとセッションが切れてしまうため、サイトの滞在時間はそこでリセットされます。セッションが切れていない場合も、ブラウザを閉じてしまうとページの滞在時間はリセットされます。ユーザーが離脱した数を離脱数、ページが表示された回数（ページビュー数）のうち離脱ページになった割合を離脱率といいます。 各ページの離脱率とコンテンツの内容を確認し、ユーザーが想定したページ（コンバージョンページ等）で離脱しているかどうかを検証します。 コンバージョンページ コンバージョンとは、サイト運営者が望むページにユーザーが辿り着くことを差します。このとき、ゴールとなるページのことをコンバージョンページといいます。コンバージョンページのページビュー数から、どれだけのユーザーがサイト運営者の望むアクションを行ったかを計測することができます。 【コンバージョンページの例】商品を購入した後の完了ページ メールマガジンの登録完了ページ アンケートの回答完了ページまた、コンバージョンページが存在しないサイトの場合は、以下の方法でユーザーのアクションを計測することができます。 仮想ページビューによるページトラッキング サイト内に仮想のページを設定して、その仮想ページのページビュー数を計測することでユーザーのアクションを計測します。 この方法は、資料のダウンロードや外部サイトへの誘導が目的のサイト、同一URLのページの遷移でゴールページを表示するようなサイトの計測に適しています。 イベントトラッキング 計測したいユーザーのアクションをイベントとして計測します。 この方法は、Q&Aサイト等でページ内リンクのクリック数を計測する場合や、上述の仮想ページビューと同様に資料のダウンロードや外部サイトへの誘導を目的としたサイトの計測に適しています。 おわりに ユーザーがサイトを訪問したとしても、コンバージョンページに辿り着けなければサイトの目的は達成されません。ユーザーが途中で離脱していないか、離脱していまう原因は何かを分析していく必要があります。 ページの滞在時間とサイトの訪問時間は難しいかもしれませんが、きちんと理解しましょう。 今後も引き続き、Webアナリスト関連の記事を書いていきますので、どうぞよろしくお願いいたします。ソリューション開発部では、資格・検定の取得や各種セミナーの受講にも力を入れています。メンバー自らが受講してみたい講座を選ぶことによって、自らの意志によってスキルアップができる環境を整えています。Webアナリスト検定 連載一覧【受けてみた】JWA公認 Webアナリスト検定 【Webアナリスト①】Webアナリストのお仕事 【Webアナリスト②】Webサイトのボトルネックを特定する 【Webアナリスト③】Webサイトへ集客を行う方法 【Webアナリスト④】集客に関する指標の用語や計算式のまとめ 【Webアナリスト⑤】Webサイトへの流入 【Webアナリスト⑥】Webサイトでの回遊（本記事）

プラットフォーム技術部の小林です。 本記事ではVPCサービスとして提供されているPrivateLinkについて、2017年11月のリリース以降エンハンスされた機能も含めた現行機能の整理と、PrivateLinkの使いどころや注意点などをまとめます。 最後に、実際にPrivateLinkを使ってプライベートサブネットからインターネットを経由せずにKinesisに対してAPIコールを実行する手順を掲載します。 PrivateLinkって何？ PrivateLinkとは「AWSへのAPIアクセスをインターネットを経由せずに行えるインターフェースタイプのVPCエンドポイント」です。 PrivateLinkを使うことでインターネットに出る必要がなくなるため「IGW、NATデバイス、VPNコネクション、パブリックIP」の導入・設定が不要になり、環境設計が必要なコンポーネントを減らすことができます。また、セキュリティ要件の厳しいシステムやクローズドな環境での稼動が必須となるシステムをAWS上に構築する際に役立ちます。 そもそもVPCエンドポイントって何？ さきほどのPrivateLinkの説明の中でPrivateLinkはインターフェースタイプのVPCエンドポイントと書きましたが、そもそもVPCエンドポイントとは何でしょうか。 VPCエンドポイントとは、VPCと他のサービス間の通信を可能にするVPCコンポーネントで、その実態は仮想デバイスです。VPCエンドポイントをVPCに作成することで、VPC内のインスタンスとVPC外のサービスとで通信ができるようになります。（詳細はVPCエンドポイントのガイドを参照してください。） VPCエンドポイントは下記の2つのタイプが提供されています。インターフェースタイプPrivateLinkと呼んでいる 実態はプライベートアドレスをもつENIゲートウェイタイプルートテーブルで送信先に対するターゲットとして指定する二つのタイプのVPCエンドポイントを使用した構成例を下図に示します。タイプによって、インスタンスとサービス間での通信経路が異なります。 ゲートウェイタイプを使用する場合はルーティング設定が必要です。図に示したルートテーブルにあるように、Destinationとして「使用するサービスのエンドポイント（この場合は東京リージョンのS3のpl-id（プレフィックスリストID））」、Targetとして「作成したVPCエンドポイントのID(vpce-id)」を指定します。このルートを設定することでVPC内部からVPC外のサービスへの通信ができるようになります。  タイプによる違いを整理：ゲートウェイとインターフェース ゲートウェイタイプとインターフェースタイプで異なる制限を下表に整理します。 [table id=12 responsive="desktop"/] カテゴリとサービス一覧 タイプによって利用できるカテゴリとサービスが異なりますので、それぞれ利用できるものを整理します。 カテゴリ一覧 まずはカテゴリの一覧です。2018年5月時点で利用できるカテゴリは下表のとおりです。 [table id=13 responsive="desktop"/] サービス一覧 つぎは各カテゴリで利用可能なサービスについて整理します。 AWSサービス まず1つめの「AWSサービス」カテゴリでは、AWSプリンシパルなサービスが提供するエンドポイントを選択できます。 下表に、現時点で提供されているサービスと対応するエンドポイントタイプ、エンドポイントをまとめています。 [table id=14 responsive="desktop"/] ※"amazon"、"aws"という語は省略してサービス名順に並べています 昨年11月のre:invent 2017で紹介されたサービスや、2018年になって新たに追加されたサービスも記載しています。いずれも東京リージョンで利用可能なサービスです。VPCエンドポイントに対応するサービスはどんどん追加されていきますので、VPCエンドポイントを使用する際にはその時点でどのサービスが利用可能なのかを確認するようにしましょう。 なお、公式のVPCエンドポイントのガイドに掲載されているサービス一覧表は最新の状態にアップデートされていないため、2018年5月時点ではこちらの表に記載の内容が正しいです。ご注意ください。 独自サービス ２つめは「独自サービス（VPCエンドポイントサービス）」です。 マネジメントコンソールでは「サービスを名前で検索」というカテゴリで表示されています。インターフェイスタイプのエンドポイントが利用可能なカテゴリです。 独自に作成したサービスをVPCエンドポイントサービスとして公開し、AWSネットワークに閉じて利用することができます。利用するにはNLBの作成が必須です。 独自サービスを利用するために図に示したように3つのステップで設定していきます。①独自アプリケーションの前段にNLBを配置して、②NLBを指定してVPCエンドポイントサービスを作成します（例：com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxxxxxx）。③そのVPCエンドポイントサービスに接続するインターフェースVPCエンドポイントを作成します。エンドポイントサービスの作成にはNLBの関連付けが必須となりますのでご注意ください。  図に示したように、PrivateLinkとNLBのVPCエンドポイントサービスを使用することで異なるVPC間の通信が可能になります。となると、VPCピアリングとの使い分けについても気になると思いますがそちらについては「VPCピアリングとの違い」の節でまとめていますので参考にしてください。 マーケットプレイスサービス 3つめはマーケットプレイスサービスです。 マネジメントコンソールでは「ご使用のAWSマーケットプレイスサービス」として表示されています。このカテゴリは2017年11月に追加されたカテゴリです。AWSマーケットプレイスが提供するサービスを利用できます。対応するタイプはインターフェイスタイプのみです。マーケットプレイスでSaaSとして提供されているサービスに対してVPCエンドポイントを作成することで、インターネットを介さずにSaaSを利用することができます。 [blogcard url="https://aws.amazon.com/jp/about-aws/whats-new/2017/11/aws-privatelink-on-aws-marketplace-now-available/"] 2018年5月時点で利用可能なVPCエンドポイント対応のマーケットプレイスサービスは下表のとおりです。 [table id=15 responsive="desktop"/] セキュリティ関連のSaaSが利用可能になっているようです。こちらも随時対応サービスが拡張されていくと思いますので、VPCエンドポイントを使用したSaaS利用を検討している方はチェックしておきましょう！ VPCピアリングとの違い 独自アプリケーションのVPCエンドポイントサービスを作成することができるようになり、異なるVPC間での通信が可能になりました。「異なるVPC間での通信」という観点で、PrivateLink機能を利用するべきか、VPCピアリングを利用するべきかを検討する際の参考情報として下表に機能の違いを整理しました。 [table id=16 responsive="desktop"/] ユースケース 上記の比較を受けて、PrivateLinkはどのような状況で使用するべきでしょうか。 独自のサービスにクローズドな環境で通信をしたい場合はPrivateLinkが適しているかもしれません。また、そのサービスがマーケットプレイスでエンドポイントサービスとして提供されているものである場合はPrivateLinkを選択しましょう。 Direct Connect接続経由のエッジツーエッジルーティングを実現したい場合は、VPCピアリング接続では実現できないのでPrivarteLinkを選択する必要があります。 VPCのCIDRブロックが重複している場合も、VPCピアリング接続での実現ができないのでPrivateLinkを使用します。すでに存在するVPC同士を接続する場合は、CIDRブロックを確認してVPCピアリング接続が可能かどうかを確認しましょう。 現在のネットワーク構成やセキュリティ要件、通信要件からはVPCピアリングとPrivateLinkのどちらを使用しても大差ないという状況であれば、設計・構築・運用の作業の大変さ、という観点でどちらがいいかを検討するのもよいでしょう。 VPCピアリングを使用する場合は、ルートテーブル/NACL/SGでアクセスを限定していくので詳細な制御ができる反面、設計や構築作業、構築後のメンテナンスが複雑になってしまうかもしれません。PrivateLinkを使用することで通信経路が可視化され構成図がシンプルになる可能性もあります。現行の運用方法に即して選択することをおすすめします。 PrivateLinkを使ってみる 実際にPrivateLinkを使ってみます。今回は下図のような簡易な構成を作成していきます。 プライベートサブネット内のインスタンスからインターネットを経由しないでKinesisのエンドポイントにAPIアクセスをしてみます。PrivateLinkの作成 VPCサービスから「エンドポイント > エンドポイントの作成」と選択します。サービスカテゴリは「AWSサービス」を選択します。 表示されたサービス名の一覧から「Kinesis-streams」サービスを選択します。（東京リージョンで作業をしているので、com.amazonaws.ap-northeast-1.kinesis-streamsと表示されています）つづいて、VPC、AZ、プライベートDNS設定、セキュリティグループを選択していきます。 VPCをプルダウンから選択すると利用可能なAZとサブネットが表示されるので、VPCエンドポイントを作成するサブネットを選択します。プライベートサブネット内のインスタンスから、AWS CLI によってVPCエンドポイントに対してHTTPS で

本連載では「まるごとおまかせZabbix」をより便利で有用なサービスとするために日々奮闘中の齊藤(沙)がアークシステム ザビ家の一員として、Zabbix に関する日々の取り組みやナレッジをご紹介していきます！【わたしに♥おまかせ Zabbix①】Zabbixの構成要素とパラメーターについて 【わたしに♥おまかせ Zabbix②】Zabbixサーバーと内部プロセスについて 【わたしに♥おまかせ Zabbix 号外】Interop Tokyo 2017 Zabbixブースに出展！ 【わたしに♥おまかせ Zabbix③】Zabbixの内部プロセスについて-続き 【わたしに♥おまかせ Zabbix④】Zabbixのデータベースについて 【わたしに♥おまかせ Zabbix⑤】Zabbixのデータベースについて – アイテム編 【わたしに♥おまかせ Zabbix⑥】Zabbixのデータベースについて – トリガー編（本記事） 【わたしに♥おまかせ Zabbix 号外】Interop