AWS Well-Architected フレームワークを活用したコスト最適化への取り組み

DSOC Infrastructure Group の大澤です。
新型コロナウイルスの影響でマスクが品薄になっていますね。花粉症なので最近は常にマスクしているのでマスクがないと辛いです。幸いにも災害対策で備蓄していたマスクがあったのでそれでなんとかしのいでいます。

最近「Cloud Cost Optimization Engineer」というロールになりました*1。Cloud Cost Optimization Engineer を日本語にすると「クラウドコスト最適化エンジニア」でそのままなのですが AWS や GCP といったクラウドコストを最適化するための取り組みや仕掛けをしていくのが主な役割となります。このロールを名乗り出る前からクラウドコストの最適化を進めてきましたが、改めてロールを立ち上げることで私が取り組んでいることを明確化することが目的です。SRE のようなメジャーな肩書が見つからず、国外でジョブオファーをいくつか見つけたのでそのまま名乗らせていただくことにしました。

AWS のコストを最適化するにあたって、闇雲に手をつけるのではなく、まずは AWS のベストプラクティスに則るのが最善だと思っています。AWS が公開している AWS Well-Architected（W-A）フレームワークの柱の1つである「コスト最適化」でコスト最適化に関するベストプラクティスが述べられています。本記事ではこれまで取り組んできたことと W-A フレームワーク「コスト最適化」のベストプラクティスを照らし合わせて紹介します。

AWS Well-Architected フレームワークとは

AWS Well-Architected（W-A）フレームワークを一言でいえば、AWS でシステム構築する際のベストプラクティスを集結したガイドラインといったところでしょうか。AWS ソリューションアーキテクトが長年にわたってさまざまなビジネス分野やユースケースを設計してきたその経験則に基づいて作られたものです。あくまで「設計の原則」であって具体的な設計や実装について触れられていません。AWS サービスを活用したり組織を改善していくことでベストプラクティスに近づけていきます。

ホワイトペーパーが公開されていて、W-Aフレームワークの設計原則やベストプラクティスを学ぶことができます。また、ホワイトペーパーに記載されている質問に回答していくことで自社のシステムがベストプラクティスにしたがっているかを照らし合わせることができます。すべての項目でベストプラクティスにしたがう必要はなく、照らし合わせることによって自社のシステムのリスクや改善点を知ることができる方が重要です。

W-Aフレームワークでは5つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化）が定義されています。本記事では5つ目の「コスト最適化」について取り上げます。

*1:インフラエンジニアとしての職務はそのままです。

VIPER の実装コストを下げるために

こんにちは！ Sansan iOS チームの髙橋佑一朗です。

Sansan iOS アプリでは現在、 VIPER をアーキテクチャとして採用していますが、VIPER の構成で実装していくに当たって1画面作るのにコードを書く量が多いなぁと少しづつ感じてくるようになりました。
そこで、今回は実装時のコストを下げるために考えたことや試したことを書いていきたいと思います。

VIPER は実装コストが高い？

VIPER についてお話をするときによく聞く話ですが 実装コストが高い というのは具体的に以下の2点から来ているのかなと思っています。

1. 画面あたりのファイル数の多さ
2. 各種 VIPER コンポーネント実装時のボイラープレート (初期化時のコード等)

順番にさらっと見ていきましょう。

1. 画面あたりのファイル数の多さ

VIPER の特徴は責務が細かく分割されているということですね。
Clean Architecture を iOS 向けに最適化したもので、元の Clean Architecture ほどではありませんが比較的細かく分けられています。
それぞれのコンポーネントの責務が明確になり、どこか一つのクラスが肥大化してしまうという事態を防ぐことができます。
また、アプリとしてロジックの置き場所などの一貫性を保ちやすくすることでコードの見通しがとてもよくなります。
反面、細かく分けられているがゆえにファイル数は多くなりがちです。

VIPER といえばこちらの記事が有名かと思いますが

cheesecakelabs.com

こちらの構造に従って VIPER を実装すると1画面あたりに必要なファイルは

• HogeViewController.swift
• Hoge.storyobard (option)
• HogePresenter.swift
• HogeInteractor.swift
• HogeRouter.swift

となり、5(storyboard がない場合は 4)ファイル作成することになります。
まだこれだけであれば苦にはならないですが、次のボイラープレートも合わさると少々しんどくなってきます。

技術書典 応援祭に「Sansan技術書典部」として参加します

DSOC Infrastructure Groupの大澤 です。
前回の記事でトレーニングジムに通う話をしましたが継続しています。成果としてベルトの穴が2つ締まりました。今年の終わりには昔のスリムな体型になっていることでしょう。

2月29日、3月1日に開催される予定だった技術書典8に「Sansan技術書典部」としてサークル参加する予定でしたが、新型コロナウイルス感染症の影響で中止になってしまいました。

とても残念でしたが、運営側のご尽力により、オンラインの技術書典 応援祭が3月7日から開催されることになりました。私たちもこの「技術書典 応援祭」に参加します。

サークル紹介および頒布本について

techbookfest.org

Sansan技術書典部からは3部出します。1冊は共著、2冊は単著です。共著の「Sansan Builders Book」は40部程度ですが物理本も販売する予定です。

Sansan iOSアプリの発信者名表示機能に関する実装・運用改善について

はじめに

Sansan事業部で法人向けクラウド名刺サービスSansanのiOSアプリ開発を担当している栗山です。

Sansanアプリには、名刺に記載されている電話番号や同僚から電話があった際に発信者名を表示する機能があります(以下 発信者名表示機能 )。

Sansanアプリの発信者名表示機能

Sansan iOSアプリで発信者名表示機能が搭載されて1年以上経ちますが、実装面と運用面で改善すべき課題が見えてきました。今回は発信者名表示機能に対して行った下記2つの改善の取り組みについてご紹介します。

1. Call Directory Extensionにおけるメモリ使用量改善 (実装面の改善)
2. Call Directory Extension内でのエラー発生を検知する仕組みの構築 (運用面の改善)

発信者名表示機能(Call Directory Extension)について

改善内容について紹介する前に、簡単にiOSアプリにおける発信者名表示機能の構成について紹介します。

iOSで発信者表示を行うためには、事前にiOSに電話番号と表示内容を登録しておく必要があります。*1

iOSへ電話番号情報を登録する際には、 Call Directory Extension という別プロセスを経由して登録する必要があります(iOSに電話番号を登録するためのAPIはCall Directory Extension内からしか利用できません)。

アプリ本体からCall Directory Extensionへ電話番号情報を渡す際には、 App Group という共通領域を経由して行います。App Groupは許可されたアプリやApp Extensionからしかアクセスできない共有ディレクトリのようなものなので、通常は何らかのファイルを使ってデータを渡します。*2

アプリとCall Directory Extension、App Groupの関係

*1:Androidの場合はOSへの事前登録がなくとも、着信時に取得した電話番号情報から自前で検索して表示内容を決定する仕組みとなっており、iOSと作りが根本的に異なっています。iOS/Android両方で発信者名表示機能を提供する際にはこの違いを考慮しておくと良いでしょう。

*2:App Grpupを使う以外にも、Keychainを使ってデータをやりとりすることもできますが、発信者名表示に使う情報は時に大量となることもあるので、Keychainを使ってのやりとりには向きません。

歴史をたどってディープラーニングを学ぶ 第四回 LeNetを作ってコンボリューショナルネットを学ぶ

こんにちは、DeepLearning老人こと糟谷勇児です。

会社では老人ですが、地域活動コミュニティでは若者扱いされギャップに驚いています。

そんなわけで今回もDeepLearningを学んでいきたいと思います。

前回はパーセプトロンを多層化することで画像認識の精度がちょっと上がるところを見てきました。

しかし、精度としてはまだまだ。 今回は畳み込み構造を持つコンボリューショナルニューラルネットを作って精度を上げていきたいと思います。  

ところで、私が新卒で会社に入ったころは、HAAR like 特徴量をAdaboostでカスケードした物体認識の手法が一般的でした。

その手法では、物体を判別するフィルタを20層など複数層重ねて、判別機を作り、画像上を走査して、物体を検出します。

 

フィルタを複数層重ねるという意味ではDeepLearningと似ていますね。

しかしDeepLearningが出てきた当時、若い人に

「DeepLearningでは画像を一枚入れれば（走査しなくても）、どこにあるか含めて判定してくれるんですよ」

と言われて、そんな魔法みたいなことあるか？ と驚きました。

勉強してみると、コンボリューショナルニューラルネットでは、判別機を走査する代わりに、中にフィルタを走査する機構を持っていて類似のことをしており、魔法でなく地続きな手法であると感じます。

コンボリューショナルネットの歴史は長く、古くは福島先生のネオコグニトロンなどがあり、第二回で言及したAlexNetも畳み込みをしています。

ただ、AlexNetはちょっと複雑でまだ難しいので、今回は1998年のLeNetを作っていきたいと思います。

プロダクト戦略開発室の業務について

初めまして。プロダクト戦略開発室でデータアナリストをしています、白石です。
今回はプロダクト戦略開発室での私の業務について書いてみようと思います。

プロダクト戦略開発室とは

そもそもプロダクト戦略開発室は今年1月に出来たばかりの組織で、CPO室とCTO室という組織が合体して出来た新しいチームです。
CPOの大津とCTOの藤倉を中心にプロダクトの戦略から採用ブランディングまで色々やっている守備範囲の広い組織です。笑

なぜこのタイミングで2つの組織が一つになったのかということですが、一言で言うとプロダクトの成長速度を加速するためだと理解しています。
Sansanでは日々、プロダクトの改善、新機能開発、新プロダクトの開発が進められており、その裏側は新しい技術や多くのエンジニアによって支えられています。どんなに良いプロダクトであっても、高い技術を持ったエンジニアがいなければプロダクトは作れませんし、その逆も然りです。
そのような状況で技術(やエンジニア組織の)戦略を司るCTOとプロダクト戦略を司るCPOがより密に連携していくフェーズになっているのだろうなと感じます。

プロダクト戦略開発室の業務

ようやく本題の業務についてですが、上で書いたように2つの異なる組織が合体して出来た組織であり、必要に応じて情報連携しながら各自専門性を発揮してプロジェクトを遂行するスタイルのため、画一的に業務を定義することができません。そのため、今回は旧CPO室が担っていたプロダクト戦略の策定にフォーカスして書いてみようと思います。

【ML Tech RPT. 】第0回 本連載を書くことについて

DSOC研究員の吉村です.

私の好きな歌の歌詞の中に、「案外第0話って後から書かれるよね」みたいなことが書いてあります。(具体的に書くと、どの曲なのかがわかるので雰囲気で書いてます。)

さて, 本連載もそれなりに回数を重ねてきたので, その歌詞のごとく第0話的にこの連載について書きたいと思います. そのため, 今回はあまり技術色は強くないので, 気軽に読んでもらえると良いかと思います.

この連載を書く目的

理由の一つ目：自らのモチベーション維持

この連載をはじめにもらったときから今に到るまで, ずっと同じ目的があってこの連載を続けています. 個人の中での一番大きな目的は単純なもので, 「自らが忙しいという理由にかまけて広く分野の知見を取り込むことを怠らない理由を作るため」です. 冒頭の一言目に毎回テンプレで書いているように, 私の職業は研究員なので現在取り組んでいる業務に関わる技術や知識についての調査は, 当然行なっています. しかし, 弊社の研究員として働く上で「イノベーション」的な側面も求められていると考えていて, それに準ずるアイデアを生み出すためには特定の分野の知識だけを都度必要に駆られて集めるだけではダメだと思っています. アイデアは, あるドメインのものを別のドメインへと転用したり, 応用したりすることで生まれるからです.

先に述べたように「広く分野の知見を取り込むこと」が私個人として重要だと思いながらも, なかなかそういった時間を優先度高く取れないので, 「業務の一環として取り込んでしまう」ことでそれを行わざるを得ないものとしています. これにより, 現在まで継続することができています.

理由の二つ目：採用目的

二つ目の理由に採用目的があります. 弊社で働くことに興味がある方々が, 実際にどんな人間がそこで働いているかを知るのはなかなか困難なことだと思っています. そのような難しさがある中で, 読者にある程度の情報を気軽に得てもらうことも私はこの連載の目的の一つとして置いています. そのため, 毎回, 前置きとして, 多少プライベートな話も盛り込みながら, 自分がどんな人間なのかを表現したりしています. また, 記事の内容についても, 最低限書いている内容について私は理解できている (はず) なので, それらに関連のある人々に新たに弊社に対する興味を持ってもらうことも期待しています.