こんにちは。R&D改めデータエンジニアリングチームの宮崎です。 普段はTensorFlowを使って、Deep Learningを学習させて画像認識モデルを作ったりしています。
Deep Learningの悩みの一つとして、学習時間が数時間から数日に及び、非常に長いという点が挙げられます。 作業効率やマシンの費用を考えると、少しでも学習時間を短くしたいです。 そこで今回はTensorFlow Profilerを用いてDeep Learningの学習時間を短縮してみたいと思います。
TensorFlow ProfilerはTensorFlowの計算時に、処理毎の所要時間などパフォーマンス情報を収集し、TensorBoard上で可視化してくれるツールです。 TensorFlow v2.2.0やv2.3.0で機能が強化され、より詳細な分析ができるようになっています。
続きを読むこんにちは、プロダクトエンジニアリング部のちょうです。最近ミーティングでコンテキストスイッチというワードが出て、これについて思うことがあり、すこし話したいと思います。
ここのコンテキストスイッチはプログラムのコンテキストスイッチではなく、毎日の仕事や勉強の中、あることをやって、その後また別のことをやる、つまり仕事の切り替えということです。仕事の切り替えがいいとか悪いのかというと、はっきり言えません。仕事の切り替えができないとそもそも仕事ができないというイメージになり、ものすごく切り替えると効率が落ちるに違いありません。
開発メンバーから見て、ミーティングが多くなると、丸一時間、丸二時間の開発時間が取れなくて、「あれ、ミーティング前に俺何をやったっけ」ということもあり、進捗があまり進まないこともあります。とはいえ、ミーティングの時間はみんな空いている（ように見える）時間帯から決めたから、簡単に変えられないです。一つ解決策はあまり要らないミーティングをキャンセルし、任意参加なら時間があるかどうかで決めるのです。残りは自分で仕事をどこまで効率化できるのか。
一番簡単なのか、予定してた時間内で完了するのです。つまりコンテキストスイッチがないということです。仕事を30分内、1時間内で完了できる細かいタスクに分けるのも効果的です。
次は、コンテキストスイッチの問題というと、前回仕事の内容はすぐに思い出せないということです。プログラムのコンテキストスイッチでしたら、切り替える前にいまやっている仕事の内容をどこかに保存します。そのように、次の仕事に入る前に、現在の仕事を保存します。具体的には
もう一つ効率的に仕事する方法は同じ種類の仕事を連続やるのです。同じ種類だとコンテキストが似ていて、スイッチしても影響は少ないです。具体的にはパソコンの前にやる仕事をまとめやったり、同じプロジェクトの仕事を連続やったりするのです。
いかがでしょうか。すこし自分の仕事の効率どうやって上げるのを分かるようになりましたか。最後に、本記事はいくつの方法を紹介したが、「ミーティングの合間」に頑張るより、連続で影響されない時間があれば一番いいということを忘れないでください。
こんにちは、最近野菜が高いのでもやしばかり食べているWebエンジニアの本間です。 そろそろレタスが食べたい...。
さて、ここ1、2年、ユニファではAmazon ECS+AWS Fargateを使用して、Railsアプリケーションを本番運用することが増えてきました。 stagingでテストしたDockerイメージがそのまま本番で使えて安心だったり、オートスケールが簡単だったりとメリットが多く、大変便利だと感じています。
ただ、そのような環境を構築する中で、vCPU数やメモリ量、およびPumaの並行性に関するパラメーターをどうしようか毎回悩んでいたため、この辺で自分の中で整理しておこうと思います。
続きを読むおはこんばんちは
ユニファのインフラみてます、すずきです。
8月に入ってから猛暑と湿度で部屋から一歩も出たくない日々が続きますね。 涼しくなれ！
さて、Terraformでステータスが更新されるまで情報が取得できない、変更できないリソースなどは、Create後すぐに別のリソースで呼び出そうとするとエラーになることがあります。 ちょっと違うけど、ACMって検証が終わるまでELBやCloudFrontで呼び出せないので Resource: aws_acm_certificate_validation を利用して待機しますよね。
そういったことが起こりうるリソースで同じことをやってみようというものです。
続きを読むみなさんこんにちは。
ユニファでサーバーサイドエンジニアをしております田渕です。
新型コロナウイルスによる突然の生活の激変が起こってから、早くも半年近くが過ぎようとしています。 （居住している国、地域などにより、体感している期間は多少異なると思いますが。。。） 弊社でもこれまでに何度か、新型コロナウイルスにまつわる投稿をこのブログの中でしてきています。 経験したことのない状況の中、色々と試行錯誤をしながら進めてきたわけですが、今回は主としてここまでの「システム運用」について振り返ってみたいと思います。
これを読んでくださっている方はおおよそご存知かと思いますが、ユニファは保育園、幼稚園、こども園様向けのプロダクト/サービスを提供しています。 したがって弊社では、新型コロナウイルスにおける緊急事態宣言のもとにおいても、平時と変わらない(あるいはそれ以上の)レベルでの安定したシステム稼働が必要でした。
何度かこちらのブログでも紹介している通り、ユニファのエンジニアは元々リモートワークが可能な勤務形態でした。 これまではリモートワークと言えばエンジニアがメインでしたが、緊急事態宣言に伴い、全社的に可能な限りリモートワークを行う体制に移行していました。
エンジニアのリモートワーク状況については、下記の記事を参考にしてください。
以前、弊社エンジニアの島田が、緊急事態宣言下での保育施設利用状況について、本ブログにてまとめてくれたことがありました。
このブログの中でも書かれている通り、3月~5月は園児さんの欠席率が大きく上がり、保育園の稼働率も例年の同時期と比べると大きく下がっていました。
ここまで聞くと、システム負荷が低いだけだし、そんなに問題はないのでは、……とお考えになるかと思います。 が、実は裏側では、日々バタバタしていました。
平常時と異なる状況なので、いつもとは少々異なる負荷の傾向が現れていました。 具体的な例では、先に紹介した保育施設の利用状況のデータをまとめたブログ中でもご紹介した「欠席コメント欄への記入率違い」などが挙げられます。
緊急事態宣言が発令された2020年4月7日以降で、明らかに利用の仕方が変わっていることが分かると思います。 この様な事例が、幾つか見受けられました。
システム保守をしているサーバーサイドエンジニアならば多くの方がシステムの利用状況、負荷状況を日常的に気にされていることと思います。 通常、システム利用の予測というのは、これまでの利用データ、負荷状況、利用者数の増加予測などを元として行っていきます。 しかしながら、新型コロナウイルスに対しての様々な新しい対応が日々、各所で行われる中では、これまでの利用データがあまり参考にならず、かつ今後の利用者数の予測を行うことは非常に難しいことでした。 基本的にシステムというのは、ある一定の想定条件下で正常に動くように各所のパラメータが調整されているので、その条件を外れれば正常に動かない箇所も出てきます。 事前に考えられる事態に対して対策はしていましたが、やはり事前には予測していなかった状況に直面しました。 それらのうちの幾つかの要素を原因としたトラブルに見舞われる中、地道にデータを分析し、暫定対応、恒久対応を行っていくことで事態の収束を行いました。
エンジニアのリモートワークはこれまでも行って来ていましたが、全社的に大多数の社員がリモートワークになるという状況は初めてのことでした。 どの会社でも同じだと思いますが、トラブルの発生の折には社内の関連部署への連絡が必須となります。 平時であれば誰かしら出社していたので、速報を口頭で伝えるということもしていたのですが、全員がリモートなのでSlackでの連絡が全てのきっかけになります。 元々エンジニアにリモート勤務が認められていた環境でしたので、Slackでの各所との話し合いは定着していたのですが、「口頭で速報を伝える」という手段を封じられるという状況はありませんでした。 もちろん、一番初めのきっかけ以降はリモートの会議体制に移行し、話し合いを行えますが、第一報はSlackです。 このことは、意外に緊急時に於いて、情報の速報性を妨げました。 というのも基本的にSlackは送ったからと言って必ずしもその場で読んでもらえるものでもないからです。
緊急事態宣言が今後再び発令されるかは分かりませんが、少なくとも暫くの間はリモートでの勤務を継続することにはなるでしょう。 となれば、上記の困ったことを放っておく訳にはいきません。
必要となるのは、下記の要素だと考えています。
このうち、「問題が発生した際の検知の早さ」に関しては、ログやシステム監視の検知条件の見直しなどを実施し、平時と異なる利用があった場合に検知が可能となるように改善を行いました。
「影響の最小化に向けた取り組み」については今回利用した暫定対策の手順等をまとめ、次回の類似事象発生時には即座に適用できるようにしました。 また、問題の原因分析、システムの状況がより分かりやすくなるように、検知ツール類の設定の見直しも行っています。 が、これに関しては実際は発生した事象ごとに必要な情報も異なってくるため、実際のところは発生ベースでの対応となってしまいます。
残る「 適切な暫定対応を行うための早期の決断」については、次項で詳細を記載する体制の整備の中で承認ルートの見直しを行っています。
トラブルが発生した際、「どこのチャンネルで」「どうやって」一報を流すのかについて、改めて整備と認識合わせを行いました。 これまでも基本的に一報を流すことはSlack上で行ってきましたが、自身のチーム内や直接的な関係者しかいないチャンネルを利用していることもあるなど、その方法が統一されていませんでした。 今回のことを機に
の再整備を実施しています。
今回は、今年2月以降で経験したことについて、備忘の意味も込めて記載してみました。 全く整備や準備が出来ていなかったという訳ではなかったのですが、非常時に於いてはほんの少し詰めの足りなかった部分が綻びとなり、顕著に形となって現れてくるものなのだなと感じています。 当たり前のことしか書かれていないのですが、当たり前のことが出来てないと非常時に困るんだ！ということを痛感した期間でもありました。 幸い、「もっとここが出来ていたらな。」という内容なので、今後も続くこの状況でもより安定してサービス提供を行えるように試行錯誤を繰り返して行こうと思っています。
自分たち自身も平常時と環境が異なる中、平常時以上のサービスレベルを保つと言うことはそれなりに苦労もありますが、一方で利用者の方から見て「動いていないと困るサービス」になれているのだ、と言うことが実感できた期間でもありました。 そのことは純粋に、有難いことだなと感じています。
ユニファでは現在も積極的に仲間を募集しています！ ご興味のある方は、お気軽にお声がけください。
皆様こんにちは、ユニファの赤沼です。
弊社では「ルクミー午睡チェック」というプロダクトで SORACOM Air Sim を使用しています。通常はセルラーモデルの iPad mini での通信用途に使っていて、API の活用はまだまだ十分にはできていないのですが、最近 Ruby のスクリプトから API を利用する機会があり、Sandbox 環境でのテストも行ったので書いてみます。
まず改めてのおさらいですが、 SORACOM のサービスは IoT 用途ということもあり、 API が充実しています。サービスの数もかなり増えており、コンソールも使いやすいのですが、API でも大半のことはできるようになっているのではないでしょうか。ドキュメントもしっかり提供されています。
全ての API についてリファレンスも提供されています。リクエスト時のパラメータの内容やレスポンスの各項目についてはもう少し説明があると良いなとは思いますが、実際に認証と各APIの実行までリファレンスページから行うことができるようになっているので、実装に組み込む前に実際のレスポンスなどが確認しやすくなっています。
実際に動かして試せる API Reference はとても便利なのですが、一つ気を付けないといけないのは、 API Reference のページから実行した内容は、実際の環境に対して実行されるということです。情報取得系の API であれば問題ないのですが、何か変更を加えたり、Sim の解約等まで行えてしまいますので、軽い気持ちで試したりするとあとで大変なことになります。また、実装に組み込む際にも開発段階ではテストが必要になると思いますが、そういう時のために SORACOM には Sandbox 環境が用意されています。Sandbox 環境で実行した内容は本番環境には影響しませんので、解約処理等の危険な処理も試すことができます。
Sandbox環境は本番環境とは別環境ではありますが、本番環境にもアカウントを持っている必要はあります。そのため本番環境のコンソールから SAM（SORACOM Access Management）ユーザを作って認証キーを生成しておく必要があります。SAMユーザがいて認証キーさえあれば良いので、権限は何も与えなくてもOKです。間違って本番環境に対して実行してしまっても影響がないように、テスト用に何も権限のない SAMユーザを作っておくのが良いかと思います。
Sandbox環境にはオペレータは用意されておらず、またGUIもないので、まずはオペレータを下記APIで作成する必要があります。
sandboxInitializeOperator API https://dev.soracom.io/jp/docs/api_sandbox/#!/Operator/sandboxInitializeOperator
Sandbox専用の API もリファレンスページから実行できますが、今回は Ruby で下記のようなコードを書いて実行しました。 init メソッドの中で実際に API にリクエストを投げています。ちなみに使用するメールアドレスは過去に使ったものと重複するとエラーになりますので、作成時には新たなメールアドレスを使用する必要があります。これを実行すると Operator ID, API Key, API Token が取得できますので、以降の API 実行にはこれらを使用します。
#! /usr/bin/env ruby require 'httpclient' require 'json' require './errors' class SoracomSandbox attr_reader :api_base_url def initialize @api_base_url = 'https://api-sandbox.soracom.io/v1' @client = HTTPClient.new end def post(url:, body: {} , header: {}) res = @client.post(url, body: body, header: header) check_status(res) JSON.parse(res.body) end def check_status(res) return if HTTP::Status::successful? res.status res_json = JSON.parse(res.body) msg = "CODE: #{res_json['code']} MSG: #{res_json['message']}" raise SoracomApiError, msg end def init(email: nil, password: nil, auth_key_id: nil, auth_key: nil) request_body = { email: email, password: password, authKeyId: auth_key_id, authKey: auth_key, registerPaymentMethod: 'true' }.to_json res_json = post(url: "#{@api_base_url}/sandbox/init", body: request_body, header: { 'Content-Type' => 'application/json' }) @operator_id = res_json['operatorId'] @api_key = res_json['apiKey'] @token = res_json['token'] @request_header = { 'Content-Type' => 'application/json', 'X-Soracom-API-Key' => @api_key, 'X-Soracom-Token' => @token } return @operator_id, @api_key, @token end end
続いてテストに使用する Sim のデータを作成します。実際に Sim を契約しなくてもいくらでも Sim を用意できるのが Sandbox 環境の良いところです。 Simデータを用意するには、架空のSimを作成してからそれを登録するという手順を踏みます。架空のSim作成には Sandbox 用の API が用意されています。
Sim作成: sandboxCreateSubscriber https://dev.soracom.io/jp/docs/api_sandbox/#!/Subscriber/sandboxCreateSubscriber
Simの登録は本番環境と同様の API で行います。
Sim登録: registerSubscriber https://dev.soracom.io/jp/docs/api/#!/Subscriber/registerSubscriber
先ほどのクラスに下記のようなメソッドを追加して実行します。
def create_sims(sim_count) sims = [] sim_count.times do res = @client.post("#{@api_base_url}/sandbox/subscribers/create", header: @request_header) res_json = JSON.parse(res.body) sims << { imsi: res_json['imsi'], msisdn: res_json['msisdn'], registration_secret: res_json['registrationSecret'] } end sims.each do |sim| request_body = { registrationSecret: sim.fetch(:registration_secret) }.to_json post(url: "#{@api_base_url}/subscribers/#{sim.fetch(:imsi)}/register", body: request_body, header: @request_header) end end
実際にはさらにオペレータ作成とSimデータの作成をラップするコードを用意して、それを毎回 Sandbox 利用時に実行しました。
#! /usr/bin/env ruby require 'optparse' require './soracom_sandbox' opt = OptionParser.new params = {} opt.on('-e EMAIL') {|v| params[:email] = v } opt.on('-i AUTH_KEY_ID') {|v| params[:auth_key_id] = v } opt.on('-k AUTH_KEY') {|v| params[:auth_key] = v } opt.on('-n NUM_OF_SUBSCRIBERS') {|v| params[:num] = v.to_i } opt.parse!(ARGV) sandbox = SoracomSandbox.new operator_id, api_key, token = sandbox.init( email: params[:email], password: 'superStrongP@ssw0rd', auth_key_id: params[:auth_key_id], auth_key: params[:auth_key] ) sandbox.create_sims(params[:num]) puts "#{operator_id},#{api_key},#{token}"
ここまでで Sandbox 環境の準備ができましたので、あとは本番と同様の API を Sandbox 環境向けに実行すればテストをすることができます。 例えば Sim 情報の取得は下記のようなメソッドを書いて実行します。
def subscribers(status: [], limit: 100) parameter = "limit=#{limit}" if not status.empty? parameter += "&" parameter += URI.encode_www_form(status_filter: "#{status.join('|')}") end get(url: "#{@api_base_url}/subscribers?#{parameter}", header: @request_header) end
これで事前準備で登録された Sim の情報が分かりますので、 Activate なども実行してみることができます。
def activate_subscribers(imsis: []) subscribers = [] imsis.each do |imsi| url = "#{@api_base_url}/subscribers/#{imsi}/activate" subscribers << post(url: url, header: @request_header) end subscribers end
こちらもラップするコードを書きました。 API_KEY と TOKEN はオペレータ作成時に取得したものを使います。
#! /usr/bin/env ruby require 'csv' require 'optparse' require './soracom' opt = OptionParser.new params = { api_key: nil, token: nil, file: nil, production: false } opt.on('-f SUBSCRIBERS_CSV_FILE') {|v| params[:file] = v } opt.on('-a API_KEY') {|v| params[:api_key] = v } opt.on('-t TOKEN') {|v| params[:token] = v } opt.on('--production') {|v| params[:production] = true } opt.parse!(ARGV) soracom = Soracom.new(production: params[:production]) soracom.set_request_header(api_key: params[:api_key], token: params[:token]) subscribers = CSV.table(params[:file], { converters: nil }) imsis = subscribers[:imsi] puts soracom.activate_subscribers(imsis: imsis).to_json
activate_subscribers メソッドや subscribers メソッドは前述の SoracomSandbox とは別の、本番と同様の API をまとめたクラスに実装しましたので参考までに抜粋して載せておきます。
#! /usr/bin/env ruby require 'httpclient' require 'json' require 'uri' require './errors' API_BASE_URL = 'https://api.soracom.io/v1' API_BASE_URL_SANDBOX = 'https://api-sandbox.soracom.io/v1' class Soracom def initialize( production: false ) @production = production @client = HTTPClient.new @api_base_url = production ? API_BASE_URL : API_BASE_URL_SANDBOX end def production? @production end def set_request_header(api_key:, token:) @request_header = { 'Content-Type' => 'application/json', 'X-Soracom-API-Key' => api_key, 'X-Soracom-Token' => token } end def post(url:, body: {} , header: {}) res = @client.post(url, body: body, header: header) check_status(res) JSON.parse(res.body) end def get(url:, header:) res = @client.get(url, header: header) check_status(res) JSON.parse(res.body) end def check_status(res) return if HTTP::Status::successful? res.status res_json = JSON.parse(res.body) msg = "CODE: #{res_json['code']} MSG: #{res_json['message']}" raise SoracomApiError, msg end def subscribers(status: [], limit: 100) parameter = "limit=#{limit}" if not status.empty? parameter += "&" parameter += URI.encode_www_form(status_filter: "#{status.join('|')}") end get(url: "#{@api_base_url}/subscribers?#{parameter}", header: @request_header) end def activate_subscribers(imsis: []) subscribers = [] imsis.each do |imsi| url = "#{@api_base_url}/subscribers/#{imsi}/activate" subscribers << post(url: url, header: @request_header) end subscribers end end
SORACOM のサービスの魅力は単に Sim での通信というだけでなく、関連する様々なサービスや API を活用することで、よりコスト効率を良くしたり、プロダクト提供までの実装コストの削減や運用時の柔軟性をあげることができるというところかと思います。 API を活用していくためにも、 Sandbox 環境でしっかりテストして安全に利用したいものです。
また弊社では複数ポジションを募集中ですので、興味ある方は是非ご連絡ください！ unifa-e.com
こんにちは。 ユニファでインフラエンジニアをしているすずきけいたです。
弊社の様なスタートアップ企業だけではなく、 広く使われるようになってきているSlack。 外部のアプリやスケジュールなどの連携もできたり、色々便利ですよね。
ただ自由で便利な半面スペースに存在する人数が400人以上になり、【この話題のCHどこ？】【CH数が多すぎ】【ここ外部協力の方いる？】などと悩む事も多いかと思います。 そこで今回は弊社のSlackの運用ルールやプレフィックス、今後の改善、CH整理に関しても紹介しようと思います。
目次
弊社ではSlackを2015年1月21日から使用しているようで、(私の入社前の事なので弊社CTO赤沼の履歴を遡った)かなり導入時期としては早いですよね。
現在パブリックChだけでも700、プライベートCHを加えると1000は越えると思われます。
当初SlackCHの命名ルールは厳格なものなく、自由に作成していたのですが、 CH数が多くなってきた事や、プレフィックス(下記記事参照)が登場した事で、弊社でも命名ルールを設けました。
SlackCHはサイドバー階層化(下記記事参照)などを除き基本アルファベット順に並ぶため、【接頭】でCHの性質を分類しています。
◆サイドバー階層化に関する記事◆
◆プレフィックスに関する記事◆
画像の様なプレフィックスを付け加える様にしております。
コーポレート本部は【#corp】、外部協力者を含むCHは【#ex】、プロジェクトに関係するものは【#pj】、 一時的なCHは【#tmp】、趣味やチャットなど仕事とは関係ない息抜きCHは【#zz】などになっております。
プレフィックス以外にもCH数は少ないですが以下のようなものを接頭につけております。 UniFaに関連する情報に届けたいものは【#unifa】、infraは【#infra】、写真事業関連は【#photo】など 誰にでもわかりやすいCH命名にするようにしています。
プレフィックスなどにも弱点があり、上記の命名ルールに従って複数のプレフィックスに該当する場合、CH名がお経の様に長くなりがちです。
例：【外部協力者を含むプロジェクトの一時的なCH】→【#ex_temp_pj_～】
あるあるですよね。名前が最後まで見えない問題です。 SlackのCH表示ペインは有限のため、SlackCHが長いとどういった内容の話をしてるかなど、中に入らないと確認できなかったりします。
下記表記は会社として決まったことでなく、あくまで色々な会社様のSlack関連記事を読んだ上での私一個人のアイディアです。
・プレフィックスを短くする(2文字統一など)。
例) #corp → #co、#photo → #ph
・3文字目にCHユーザーのレベル感を数字で表す。
例) #corp_enployee_must～ → #co1
・4文字目に外部協力者の人が含まれているかを判別する。
y → いる n → いない
例) #ex_corp_everyone_talk → #co4y_talk
このように決めを細かくし浸透させることで、そのCHはどういうものかというのが短く伝わりやすく、表示ペイン内にも収まりやすい。
また同時に外部の人間はわかりにくいと言う効果もあり、上場を目指すスタートアップ企業としても、セキュリティ面を考えるエンジニアとしても効果が期待できそうだ。
現在700以上あるパブリックCHもその多くは発言がなく、参加者もいないものが散見される状態で、今までCHを作成したままで放置になっている【ゾンビCH】を一掃しようと画策しております。
ここも決めの問題になるのですが【半年間発言がないCH】、【参加者が0名のCH】をAPIを使って定期的に強制アーカイブを行おうと思っております。
そのアーカイブに関してはまた別の記事で発表できたらいいかなと思います。
【#unifa_all_must】
UniFaに関わる全員に伝えるmustな情報CH
【#pj_廊下を写真でステキ空間にしようの会】
我が子の写真を定期的に募集、投票、掲示までするCH。率先的に行っていて、とてもUniFaらしい。
【#tmp_check_ozo_202007】
2020年7月のOZO(勤怠報告システム)を提出したら抜けるCH。みんなの悲鳴が聞こえます。誰が残っているのかわかりやすくていいですよね。
【#zz_times_keita】
私の心のつぶやきやスケジュールなどリマインドCH。ミーティング15分前！とか刻めて役にたってます。
【#zz_we_love_coffee】
コーヒー大好きな皆さんが集まるCH。レベルが高いコーヒー談義してます。沼です。
小さなノウハウの集積ですが、ゼロから考えるのって面白いですよね。 SlackCHの整理に悩んでいる方の参考になれば幸いです！
