非エンジニア部門とRedmineで情報共有するためのTips

はじめに

こんばんは。 ishturkです。

タスク管理してますか?

弊社では開発部門のタスク管理に Redmine を活用しています。

f:id:photosynth-inc:20181210013819p:plain

今回は開発部門だけでなくCS(カスタマーサクセス)部門と一緒にRedmineを使うためのTipsです。

CS部門と開発部門の架け橋として

CS部門では、顧客管理ツールがあるので、Redmineはメインではありません。統合できれば素敵ですが、それはまた別な話。

なので、開発部門と連携する場合は RedmineをCSにも使ってもらっています。

CS ≠ エンジニア

ここで課題になるのが、CS部門はエンジニアでないということです。

リテラシーにばらつきがあるので、

  • 大体こういうもんでしょ?
  • こうなってるはずだ

みたいな感覚がありません。まぁエンジニアだからといってそうだとは(ry

だれとでも一緒に使えるようにするTips

弊社でうまくいったアイディアをいくつか紹介します

アバターをいれる

見た目がフレンドリーになるのでよいです。見た目でハードルを下げるのはとても大事なことです。

Gravatorに依存したくないので、ローカルアバタープラグインを使ってます。

github.com

どこになにを書いたらいいかひと目でわかるように

まずトラッカーを選択して優先度はこれで説明にはこれを書いて。。。。

説明する側もされる側も「うっ」 ってなります。

デフォルト設定

操作回数を減らします。そのために

  • 専用のサブプロジェクトをつくる
  • 専用のトラッカーをつくる
  • プロジェクトのトラッカーをデフォルト設定して、なるべくそれしか使わない

トラッカーってなに?? になる人が多いので、そもそも触らせないのが良いです。

テンプレートの活用

これがとても便利な機能なのでイチオシ。この記事で一番のおすすめです。

まずプラグインを入れます。

github.com

※テンプレートの説明はこのサイトがわかりやすかったです。

Redmineでチケットのテンプレートを設定する | CodeLab

テンプレートを作成します。トラッカーを指定できるので、適用したいトラッカーを選びましょう。先述しましたが、専用のトラッカーが良いです。

専用であれば、ここで、デフォルト値として設定することで、「新しいチケット」を選ぶと、テンプレートを選択するところまで一発で遷移します。

f:id:photosynth-inc:20181210013416p:plain

ここでもう一つの役割をもたせます。入力する人へのメッセージを記載します。

たとえば、下のように設定しています。

f:id:photosynth-inc:20181210012717p:plain

入力してくれてありがとう! とか入れておくと良いといいですね。(今思いついたので採用します)

自分で悩ませない

Remineで悩んだらこの人に聞け!というのを強めにインプットしておきます。私がRedmineおじさんです!

  • 悩む時間を短くする
  • 嵌りどころを教えてもらえるので改善できる

後者がとても重要で、使い慣れているとなかなか気づかない落とし穴にハマってくれるので、なるほど!となるわけです。win-winですね。

終わりに

CS部門とRedmineで情報共有するためのTipsを紹介しました。まだまだ小ネタはあるので、またどこかで紹介したいと思います。

ハッピータスク管理!

おまけ

Photosynthでは一緒にはたらく仲間を募集しています!

採用情報 | 株式会社フォトシンス Photosynth Inc.

ネットスピードをRaspberry PiとGASでメトリクスする

どもー、 id:kazuph1986 です。

この記事はAkerun Advent Calendar 2018の5日目の記事です(そんな気がするのです)。

今日は家のネットスピードがヤバすぎ(遅い)なので、実際にどれくらいの通信速度が出るかを収集してみました。

Setup

今回はこれを使います。環境はRaspberry Piを家の回線に有線接続してます。

github.com

CLI上でSpeedTestできる便利なやつです。

インストール

curl -Lo speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod +x speedtest-cli

使い方はとっても簡単で特にオプションを付けずに叩けばOKです。

$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Softbank BB (126.199.26.185)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Love4Taylor (Tokyo) [3.36 km]: 50.447 ms
Testing download speed................................................................................
Download: 6.70 Mbit/s
Testing upload speed................................................................................................
Upload: 4.17 Mbit/s

うん、遅いですね。

以下のようにサーバーを指定して叩くことも可能です。

# 日本のサーバーを選択して…
$ speedtest-cli --list | grep "Japan"

# 番号を直接指定
$ speedtest-cli --server 15047

# 出力をシンプルにすることもできます
$ speedtest-cli --server 15047 --simple
Ping: 55.566 ms
Download: 14.01 Mbit/s
Upload: 4.17 Mbit/s

GasでAPIの作成

スプレッドシートを作成して、スクリプトエディタを開いて以下のように書きました。

function doPost(e){
  if (e.parameter.net_speed_ping) {
    var data = [
      new Date(),
      e.parameter.net_speed_ping, // ms
      e.parameter.net_speed_download, // mbps
      e.parameter.net_speed_upload // mbps
    ];

    addData("home metrics net_speed", data);
  }

  return ContentService.createTextOutput("ok");
}

function addData(sheetName, data){
  var sheet = SpreadsheetApp.openById("<YOUR_SPREADSHEET_ID>").getSheetByName(sheetName);
  sheet.appendRow(data)
}

このスクリプトAPIとしての公開方法はこちらを御覧ください。

qiita.com

APIを叩く

Raspberry Pi上に以下のようなスクリプトを置いて叩いています。shellしか使ってないのでお手軽ですね。

#!/bin/bash

# Ping: 35.752 ms
# Download: 7.37 Mbits/s
# Upload: 0.59 Mbits/s
echo `date` start speed test
speedtest-cli --server 15047 --simple | tee .net_speed.log
net_speed_ping=$(cat .net_speed.log | cut -d' ' -f2 | awk 'NR==1')
net_speed_download=$(cat .net_speed.log | cut -d' ' -f2 | awk 'NR==2')
net_speed_upload=$(cat .net_speed.log | cut -d' ' -f2 | awk 'NR==3')

url=https://script.google.com/macros/s/<YOUR_GAS_API_URL>/exec
curl $url \
    -XPOST \
    -d net_speed_ping=$net_speed_ping \
    -d net_speed_download=$net_speed_download \
    -d net_speed_upload=$net_speed_upload
echo `date` end speed test

あとは以下のようなcronを設置すれば完成です。

*/5 * * * * root /home/pi/post_net_speed.sh >> /var/log/syslog 2>&1

5分毎としました。

結果

以下のようにデータが溜まりはじめました。 f:id:photosynth-inc:20181207093511p:plain

グラフにするとこんな感じ。6日間くらいのデータです。わかりやすく山と谷が出てます。 f:id:photosynth-inc:20181207093703p:plain

ということで結果としては、一番ネットをいじりたい20時〜24時で1〜数Mbps程度に下がり、深夜帯に復活していき朝6時にピークの25Mbpsくらいの速度が出るという感じでした。 これだと朝に早起きして好きなことをした方が良さそうです。

まとめ

Raspberry PiとGASで簡単に家の回線スピードを可視化してみました。

結果的には、「まあみんな使う時間帯は遅くなるよね・・・」という感じで「わかっていた」という気持ちもあるのですが、 妻にこの実態を見せたことで「ネットもっと速くして」という感じで話が進み、現在導入中になってます。

やはり数字で語るのは効果的ですね。

ということで、Nuro契約しました(改善結果はまたどこかで上げます)。

ではでは。


Photosynthでは一緒にはたらく仲間を募集しています!

採用情報 | 株式会社フォトシンス Photosynth Inc.

社内ツールアクセスのためにVPNではなくProxy Serverを構築する

どもー、 id:kazuph1986 です。

この記事はAkerun Advent Calendar 2018の3日目の記事です。

今日はサクッとEC2を利用してProxy Serverを構築した話です。

経緯

弊社では、エンジニアおよびカスタマーサポートのために社内ツールを構築・作成しており、社内外合わせた4, 5個程度を常時使いながら業務を行っています(作業内容がカニバっているものは統合のための開発も行っているので、減ったりもします)。

そしてそのすべてが社内からのIPでなければアクセスできないようになっているので、以前はどうしても社外からのアクセス必要な場合に、個人ごとにVPNの権限を渡していたのですが、そもそも社内ツールにアクセスはしたいが、社内ネットワークにつなぎたいわけではないので、権限を与えすぎという状況が生まれていました。またVPNの権限を渡せるのはある程度入社期間を経ていたり、一定以上のリテラシーがあるとCTOおよび上長から認められた人だけだったので、場合によっては特定の人に対して権限を付与することがずっとできないという状況も生まれていました。

つまりVPN(だけ)では適切な権限管理をすることができないので、融通を利かせることができる認証方式を求めていたわけでした。

解決

そこで、一定以上の強度で認証できかつ簡単な『古き良きProxy Server』を使って認証できる仕組みを構築しました。 これであれば接続毎に社内のネットワークに入る必要もありませんし、人毎に見た履歴がわかったり、見れるサイトも制限できるので、とても便利です。

またこれは今後やる予定ですが、Proxy Serverの全段にさらにAWSのCognitoなども挟むことで、さらに柔軟な権限管理も可能です。 現在はツールごとに個別にアカウント認証機能も開発していたのですが、それももしかしたら統一できるかもしれません。

これは便利。

ということで早速構築してみましょう。

1. EC2を構築する

適当なタイプのインスタンスを作ってください。

2. Squidをインストール

今回は弊社の超Web強いエンジニアのおすすめもありSquidを使ってみました。 最初「よくわからんのでnginxでよくね」って思ったのですが、毛嫌いせずに使ってみたらむしろProxyについてはSquidはすごい簡単だったので正解でした。

ちなみにここで言っているProxyはFoward Proxyです。

構築方法は以下。

sudo yum -y install squid
sudo yum -y install httpd-tools
systemctl status squid.service
sudo systemctl enable squid.service
sudo systemctl start squid.service

3. 設定

ファイルは /etc/squid/squid.conf です。

僕はこんな感じで編集しました。ホワイトリスト方式で、社内ツールだけアクセスできるようにしてます。whitelistの中身やmy_teamという単語、http_portは適当に変えてください。 http_access allow password whitelis によって、パスワード認証を通過しかつホワイトリストのURLのときだけアクセスを許可するようにしています。

+ # whitelist
+ acl whitelist dstdomain "/etc/squid/whitelist"

+ # auth
+ auth_param digest program /usr/lib64/squid/digest_file_auth /etc/squid/digest_auth
+ auth_param digest children 3
+ # auth_param digest realm Proxy Web Server
+ auth_param digest realm my_team
+ auth_param digest nonce_garbage_interval 5 minutes
+ auth_param digest nonce_max_duration 30 minutes
+ auth_param digest nonce_max_count 50
+ acl password proxy_auth REQUIRED

+ # whitelistの場合は以下
+ http_access allow password whitelis

+ http_port <適当なポート番号>
# And finally deny all other access to this proxy
http_access deny all

/etc/squid/whitelist (グーグルとAWSはあとからアセット系のロードのために追加しました)

.yourapp.com
.google.com
.amazonaws.com
.aws.amazon.com
.cloudfront.net
.amazonwebservices.com

設定後に再起動してください。

4. ユーザー登録

あとはユーザー登録します。

sudo htdigest /etc/squid/digest_auth my_team kazuph
Adding user kazuph in realm my_team
New password:
Re-type new password:

以上で完了です。

5. logを確認する

sudo tail -f /var/log/squid/access.log

6. (おまけ)ユーザーを一括で登録する

ユーザー登録時にいちいちランダムに生成したパスワードを貼っ付けるのがめんどくさかったので、以下のように自動化しました。

setup

sudo yum install expect

script

proxy_pass.sh

#!/bin/bash

digest_gen () {
    name=$1
    pass=$2
    expect -c "
        spawn sudo htdigest /etc/squid/digest_auth my_team $name
        expect \"New password:\"
        send \"$pass\n\"
        expect \"Re-type new password:\"
        send \"$pass\n\"
        expect \"$\"
    "
}

for name in $(cat list); do
    echo --START--
    echo USERNAME $name
    pass=$(mkpasswd -l 20 -s 0)
    echo PASSWORD $pass
    digest_gen $name $pass
    echo $name $pass >> pwlist
    echo --DONE--
done

listは以下のような想定

taro.yamada
jiro.sato
santaro.suzuki

以上で構築完了です。

まとめ

やってみたら案外簡単だったので、むしろVPNを構築を考えているのであれば一考の価値ありです。 最初検索したらパスワードは平文でしか保存できないと出てきたのですが、んなわけあるかーい!って思ったらちゃんとハッシュ化されたパスワードで保存できました。 自分で一次情報を調べるって大事ですね。

途中で書いたように、今後はCognitoと連携するとめっちゃいい感じに権限管理ができると思うので、それについてもチャレンジしてみます(Elasticsearch構築のときに本当は試したんですけどね)。

ということで、今回はProxy Server構築をする話でした。

ではでは。


Photosynthでは一緒にはたらく仲間を募集しております!

採用情報 | 株式会社フォトシンス Photosynth Inc.

チーム開発でC言語API仕様を共有するメソッド 〜 Doxygenのすすめ

こんばんは。 ishturk です。 この記事は Akerun Advent calendar 2日目の記事です。

Akreun の組み込み開発ではC言語がなかなかの割合を占めています。

過去にモジュール設計の話を

qiita.com

で書きました。どうモジュールを分けるかはとても重要な設計タームです。

背景

さて、モジュールをうまく分割できたらそれぞれ実装します。担当者は複数かもしれません。

この記事では、分けたモジュール間のAPI仕様をチーム間でどう共有したら捗るかの一例をご紹介します。

API仕様をチーム間でどう共有したら捗るか」です。大事なことなので2回言いました(書きました)

何を解決するか

  • API仕様書がどこにあるかわからない
  • 仕様を変えたときにどこを変えたらいいかわからない
  • ソースとAPI仕様書が乖離している
  • 人によってAPI仕様書の書き方が違いすぎて困る

結論

いきなり結論です

Doxygen形式で公開ヘッダファイルにコメントを記載するのがいろいろな面でシンプルで良いです。

たぶん導入しようとして挫折したPMの方もいるんじゃないでしょうか。。。多分それは、がんばりすぎたのです。

Doxygen の紹介

Doxygen形式ってなんぞや?の方ももちろん多いと思いますのでざっくり解説します。

www.doxygen.jp

簡単に言うと

  • 記法にそった書き方をするとソースファイル・ヘッダファイルからドキュメントを自動生成してくれるツール

です。具体的には、

  • 関数の入力・出力引数と意味を明示できる
  • 関数の戻り値の意味を列挙できる
  • enumやstructのメンバにコメントできる

他にも

  • モジュール間の依存関係を視覚化してくれる
  • HTML、Latex、RTF などの形式で出力できる

などなど魅力的な機能もあります。

けっこうアチコチで使われていて、僕らがお世話になっている Nordic さんの SDK API 仕様書も Doxygenで生成されていました。

https://www.nordicsemi.com/DocLib/Content/SDK_Doc/nRF5_SDK/v15-0-0/index

API仕様をチーム間でどう共有したら捗るか

本題です。

ルールを決める

単純なルールを決めます。

他の人(モジュール)から呼ばれる関数には必ず定義のすぐ上にdoxygen形式でコメントを記載する。 使う相手に伝えたいこともdoxygen形式でコメントを記載する。

ルールはこれだけです。

やってみる

僕が推奨する最低限の内容はこんな感じです。

typedef enum {
  SUCCESS, ///< 成功
  PARAM_ERROR, ///< パラメータエラー
  GENERAL_ERROR, ///< その他のエラー
} HogeRet;

/**
 * @brief ほげをdoする
 * @param a [in] ほげの値
 * @param b [out] doした結果を格納するバッファのポインタ
 * @retval SUCCESS 問題なし
 * @retval GENREAL_ERROR エラー
 * @note リエントラント非対応
*/
HogeRet hogedo(int a, int*b);

void hikoukaifunc(int c);

書き方を解説します。

enum

///< メンバのコメント

enum や struct で説明が必要な場合は書きます。

関数

ちなみに @func(関数名を書くための記法) はコメントを全然ちがう場所に書く場合に使うのですが「必ず定義のすぐ上にdoxygen形式でコメントを記載する。」とルール化すれば不要な記法です。

/**

アスタリスク2つ以上が必須です。 (過去に僕はこれで一晩悩みました)

@brief 関数の説明

関数の説明を書きます。

@param 変数名 [in/out] 説明

型は不要です。変数名から自動で判断してくれます。

@retval 値

返し得る値のリストです。書いてないものは書かない。

@note コメント

こういう使い方しないでね〜という実装ってよくあると思うんです。ここに書く。

Doxygen によるドキュメントの生成

しません (ドヤッ

どういうこと?

ここで強調したいのが 「 API仕様をチーム間でどう共有したら捗るか」(3回目)が目的であることです。

なので、十分目的は達成しています。

doxygen形式で書くことをルール化したことで

  • フォーマットを世の中で使われている方法に統一する(オレオレじゃないというのが重要
  • 公開ヘッダに必ず残る = ヘッダを見れば仕様がわかる
  • ドキュメントを別管理しないので仕様変更しやすい(実装者がdoxygenコメントも直せばOK

という旨味があります。

また、

  • API仕様作成時点でヘッダができる = スタブ実装が(ほぼ)不要

といういいこともありました。

なぜドキュメント化しないのか

ドキュメントを自動生成する運用まで設計しようとすると、ステークホルダーが増えるので、スタートしづらいと思います。ここで挫折しちゃうパターンがそこそこあるようで。

自動生成できる(はずな)ソースコードになっていれば、あとから生成することもできるので、まずはソースコードだけで運用してみてはいかがでしょうか。

実装する場合ってgrepしちゃうからドキュメント見ないんですよね。

もちろん、doxygen形式で記載していれば、doxygenコマンドをCIに組み込むだけです。その話はまたどこかで。

おわりに

API仕様をチーム間でどう共有したら捗るか をご紹介しました 。ミスコミュニケーションを撲滅して快適な組み込み開発をしましょう。

おまけ

Photosynthでは一緒にはたらく仲間を募集しております!

採用情報 | 株式会社フォトシンス Photosynth Inc.

大きくなってきたIoTプロダクトのログ活用について 〜Amazon Elasticsearch Service篇〜

ども、id:kazuph1986 です。この記事は、Akerun Advent Calendar 2018の1日目の記事です。

今回は弊社のログの活用をするためにサクッとElasticsearchを導入して業務改善を行った話をします。

背景

弊社では利用関連のデータはすべてDBに保持しており、データをRails consoleやRedashを用いて確認・分析を行っております。

ですが、IoT機器自体のログをすべてDBに含めるのは(負荷・量・金銭コスト的に)無理があったため、そのままサーバーのログとして吐き出しているだけのものもあります。

弊社ではログの収集については、

  • リアルタイムにCloudWatchLogsに送信
  • 日次でS3に送信

しており、それぞれ

  • 短期間の生ログの確認用
  • 長期間の保存用

という分け方をしていました。

サポートのために弊社のカスタマーサポート(以下、CS)のメンバーと一緒にエンジニアが調査を行うことも多いのですが、このCloudWatchLogsの方のデータについては、クエリや集計の弱さ、AWS Conosleの権限の中にエンジニア以外が含まれてくる煩雑さ(IAM)等の理由により、そのままではCSメンバーには提供してませんでした。そのためエンジニアが調査作業のたびにCSから依頼を受け、AWSのconsoleを開きログの確認をせざるを得ない状況になっていました。

解決方法

そ・こ・で!どうしようと思っていた時にAWSのCloudwatchLogsがElasticsearchへの吐き出しに標準で対応していると知り、

「もしかして一瞬でできる??」

と思いやってみたのでした。

結果的に1日くらいの工数で構築できたので、もし似たようなケースであれば、かなりおすすめです。 しかも僕はハマってしまったので1日でしたが、わかっていれば1, 2時間くらいで終わると思います。

はまりポイントは以下でした。最も時間がかかったのが地味に一番上のやつです。AWS力を上げないとなと思いました。

  • デフォで生成されるvpc*********.comのURLがPrivate IPのを返却していると気づいてなかった(EC2のような感覚でネットワークパスを通そうとしてしまった)
  • 弊社のログがLTSV形式だったのでLambda側のパースの処理でちょっと試行錯誤が必要だった
  • Elasticsearch自体のindexの概念の学習コスト

それでは実際にやってみましょう!

1. Elasticsearchのインスタンスを立ち上げる

AWSは「Amazon Elasticsearch Service(以下、ES)」というフルマネージドなサービスを提供しています。 ESの画面に行ったら「新しいドメインの作成」からサクッと作成できます。

f:id:photosynth-inc:20181201101452p:plain
AWS Console ES

次の画面で、ドメイン名とESのバージョンの指定ができます。

f:id:photosynth-inc:20181201101920p:plain

次へを押すと、インスタンスタイプ等の設定画面に行きます。最初はt2系で立てたのですが、インスタンスのタイプ毎にストレージ上限が決まっているため、容量が必要になるたびに増やす必要があります。ただ一旦低いので立てておいて、あとからスケールアップするのは簡単だったので、お試しではt2でも問題ないかもしれません。ちなみにt2系はすべて35Gが上限です。

docs.aws.amazon.com

次にネットワーク構成を選択します。ほとんどの場合社内利用だと思いますので、VPCアクセスで問題ないと思います。

f:id:photosynth-inc:20181201102851p:plain

次に認証ですが、AWSのCognitoを挟むこともできますし、単にVPCでのアクセス制限もできます。今回は「IAM認証情報を使用した署名リクエストを要求しない」にしました。

f:id:photosynth-inc:20181201103034p:plain

これで必須のものを全部選択して、確認画面に行き、「確認」を押すことでインスタンスの生成がはじまります。

2. CloudWatchLogsとの連携

連携は非常に簡単です。ESへのストリーミングを開始を押し、

f:id:photosynth-inc:20181201103545p:plain

先程作成したESのクラスタとログの形式を指定します。 右下の「ストリーミングを開始」ボタンを押すと即刻連携がはじまります。

f:id:photosynth-inc:20181201103713p:plain

簡単ですね^^

3. (必要なら)Lambdaを編集する

上記まで完了するとLambdaの関数も自動で作成されます。 そうです、実は、連携と言って起きながら、AWSさんはそれを実現するためのLambdaを作成しているだけなのでした。

f:id:photosynth-inc:20181201104245p:plain

Lambdaですので、普通のソースを編集できます(JS)。

弊社ではログをLTSVで出力しているため、これをES様に変換するスクリプトに修正します。 100行目くらいにある buildSource を少し修正します。

function buildSource(message, extractedFields) {
    var log={};
    
    // LTSVとしてパースする
    message
    .split(/\t/)
    .map(function(s) {
        var res = s.match(/(.+?):(.*?)$/);
        return [res[1], res[2]];
    }).map(function(ary){
        log[ary[0]] = ary[1]
    });

    // 必要に応じて方を合わせる
    // 特にnumber型にしたいが、空となってしまう場合は代替の数字を用意する
    // ES側でindexの修正でも対応できるが、日次でindexを作り直す場合に戻ってしまうので、
    // 出力側で注意する
    log['time'] =  moment.parseZone(log['time'], 'DD:hh:mm:ss').toISOString();
    log['size'] === '-' ? -1 : parseInt(log['size'])
    log['reqtime'] === '-' ? -1.0 : parseFloat(log['reqtime'])

    return log;
   ...
}

型が合わないとES側で適切に検索・集計ができないので、おそらくここで試行錯誤することになります。 基本的に今回はストリームを想定しているので、過去分を間違って登録してしまった場合は、ES側のデータを全部吹っ飛ばすなどしてやり直しましょう。

逆に過去分を全部集計するような場合は、またS3+Athenaが向いていると思うので、それは別途書きます。

4. ESのkibanaを見れるようにする

上記までがうまくいっていると、実際にESの方で可視化ができるようになります。 AWSで構築するESには最初からkibanaというビジュアライゼーションツールが入っているので、こちらを利用しましょう(AWSだからというかESについている)。

kibanaのURLもESの管理画面から確認できます。

f:id:photosynth-inc:20181201105707p:plain

ですが、冒頭言ったように、普通にこのvpc〜のURLをクリックしても、VPC内のPrivateなIPを返すため、会社などのPCからはそのままでは閲覧できません。 VPCに対してVPNを張るか、プロキシサーバーやLBを追加する必要があります。

弊社では、社内閲覧のために以下の2種類の方法を使っています。

  • Route53 + ALBで見えるようにする
  • プロキシサーバーを構築して見えるようにする

ALBを利用する方法については、クラスメソッドさんの記事が詳しいです。

dev.classmethod.jp

本当の意味でPublicにするかは設定次第で、弊社では社内IPからのみ許可するようにALBのセキュリティグループを設定しています。

Route53にてわかりやすいドメインをつけることで、社内での利用がしやすくなっています。

またプロキシサーバーについてはsquidを用いてサクッと構築してます。 こちらについても、プロキシサーバー自体の記事を別日程で書く予定なので、そちらを待ちください。

というわけでこんな感じでKibanaが見れるようになるので、あとはKibanaのビジュアライゼーションツールによって様々なグラフが生成できます。 またAPIも充実しているので、IN/OUTで色々な用途に利用できそうです。

f:id:photosynth-inc:20181201110827p:plain

まとめ

DBにないログの情報を活用するためにESを構築する方法を紹介しました。 構築もAWSのUIに則って作業することで、半自動で構築が可能です。 すごい便利ですね。

実は、これをやるにあたり、目黒のAWS Loftにいるソリューションアーキテクトの方に相談に乗ってもらいました。 最初はAthenaでやるつもりで相談したら、ESの方法を紹介してもらい、そこまで便利そうならということで、ESを選択しましたが大正解でした。

こんな感じで、単に質問に答える以上に提案ももらえるのはありがたいことです。 東京にいるならサクッと相談できるLoftの利用は最高に便利です。AWSを利用しているのであれば誰でも入れますので、気軽に行ってみてくださいね!

aws.amazon.com

それでは。


弊社ではデータ分析に興味があるWebエンジニアの方も募集しております。 詳しくを以下を御覧ください。

採用情報 | 株式会社フォトシンス Photosynth Inc.

新Apple3人衆が届きました

開発用にAppleの新製品を購入しました!総額約30万円。ヤバイ。

この3機種をこの瞬間に揃えている人はそんなにいないのでは?!

※経費です

f:id:photosynth-inc:20180921122133j:plain

f:id:photosynth-inc:20180921122154j:plain

バリバリ試しますよ!

builderscon tokyo 2018 に登壇してきました

Photosynth 組み込みエンジニアの石井です。ブログの内容により肩書が変わります。

9月6〜8に慶応大学で開催されていた builderscon tokyo 2018 に弊社エンジニア3名登壇してきました。

また、Photosynthはスポンサーとしても関わらせていただいてます。技術大事にする会社ですね(どや

IoT開発の闇

※ 諸事情によりスライドは非公開です。雰囲気は @kazuph のブログ

builderscon tokyo 2018 で前夜祭とDay1のダブルで発表してきました - 僕のYak Shavingは終わらない

でお楽しみください

産業でガチ利用されるRaspberry Piの話

speakerdeck.com

ハードウェアをE2Eテストできないなんて誰が言った? - IoTのテストを自動化するメソッド 【前半】

speakerdeck.com

ハードウェアをE2Eテストできないなんて誰が言った? - IoTのテストを自動化するメソッド 【後半】

speakerdeck.com

登壇・参加してみて

私は参加も含めて初めてだったのですが、登壇者、参加者の熱量の凄さにアテられました。みんな(もちろんいい意味で)なまら鼻息荒い。テーマが「知らなかった、を聞く」だけあって、広く深く技術に関わっていく心意気のある方ばかりでした。勉強会やカンファレンスの参加者って10%の能動的な人と90%の受動的な人で構成されていると思ってました(偏見)が、100%が能動的な人。

これだけのイベントで登壇させていただけたのはとてもとても光栄なことです。

主催者や運営スタッフ、スポンサー、参加社の皆様、本当にありがとうございます!また来年も参加します!

あと、ボク個人てきには Winで開発してた時代にめちゃめちゃお世話になった @kaoriya さんにあえたのが感動でした。

おまけ

Akerun Pro とツーショットの写真を撮っていただけたのであげておきます

f:id:photosynth-inc:20180917215101j:plain

おわりに

フォトシンスでは一緒にものづくりができるエンジニアを募集してます!!!

www.wantedly.com

www.wantedly.com