JSUG勉強会 2017年その7 俺たちのマイクロサービスへ行ってきた
週末風邪で倒れてたので初投稿です。
教科書の話ではなく、実プロジェクトの経験ベースの貴重な発表がきけました。
無理をしないマイクロサービス
資料は非公開。
実際にマイクロサービスを導入したときの話。
無理をしない
自分たちの体制や得意な技術に合うやり方で、これまでやりたくてもできなかったことをする。
実際にやったこと
最初はBigMonolith。リリーススピードをあげたい
- コンフリクトが発生すると解消に時間かかる
バックエンドをチーム毎に分割して、フロントエンドにUIサービスを置いてAPIで呼ぶ
- フロントエンドのUIが全チームで共有するため、フロントエンドでコンフリクトが発生
コンポーネント指向のSPAやBFFは、サーバーサイドスキル中心のチームで採用するのは厳しい（無理をする）
各サービスがUIまで持つ完結したアプリケーションの構成
- 注文、カート、オーダーといったアプリケーションが画面遷移で繋がってる構成
ユーザー情報の連携はもともとあったSSOの仕組みを利用
リンクのURLはSpringCloudConfigで一括管理
- 開発中とプロダクションで値の切替もできる
他のサービスと連携する部分はAPI
API呼び出しで障害が発生すると、障害の連鎖で最悪LBがダウンする
- 障害の連鎖を防ぐためのサーキットブレーカー（Hystrix）の導入
- Fallbackが注目されがちだが、障害の発生したAPIにアクセスさせないことが重要な目的
各APIにHystrixのアノテーションを書きたくないため、APIゲートウェイを導入しそこでサーキットブレーカーを設定
- 各チームの作業コストは0
Zuul2の開発は停滞中。yamlで定義がかけるSpringCloudGatewayが開発進行中
サービスディスカバリーは使わず、Cloud FoundryのRouterを利用
サービスディスカバリーの種類
CloudFoundryもサービスディスカバリーをプラットフォームで提供する予定
- アプリケーション側ではなく、プラットフォーム側でやるべき
最近はEnvoyがホット
- サービスメッシュを形成する
- メッシュを管理するIstioもホット
APIでクラスを共有すると、サービス側の変更でクライアントも影響を受けるので、サービス側がクライアントを提供する
- 破壊的変更がない限りは影響なし
k8sやCloudFoundryのようなXaaSを利用する
- k8sはコンテナから先を実装するCaaS
- CloudFoundryはコンテナやランタイム/ミドルウェアまでをプラットフォームが提供
Spring Bootはコンテナにする利点があまりないのでCloud Foundry
- コンテナにしてもjava -jarをするだけ
CI/CDのパイプラインはconcourse
- Concourse: CI that scales with your project
- Yamlで定義でき、1チームが作成した後コピペで増やせる
重要なこと
- やりたいこと(これまでできなかったこと)が解決できているか
- 技術を目的にしない
俺のマイクロサービス
- マイクロサービスは目指すものではなく結果論
- マイクロサービスには守破離の守がなく、こうやれば始められるというものがない
ECサイトの例
- もともとはオフショアで作られたシステムで品質がひどい
-
- 既存システムに比べて安定したが問題も
APIが画面項目とひも付き、再利用できない
- RDBの負荷が高い
- Tomcatを再起動するとセッションが初期化されるため、誰もアクセスして来ないであろう深夜にしかリリースできない
- 非同期処理がやっつけ
15のやったこと
1.SpringBootの導入
2.サービスディスカバリーとロードバランス
- Eurekaを導入。サービスメッシュは検討中
3.キューイング
- ファイルでやってたところを、オープンな仕様のAMQP（RabbitMQ）を導入
- 今ならSpringCloudStreamとkafka使うかも
4.セッションレプリケーション
- SpringSession＋Hazelcastを利用。今の所は問題ないが、ヘビーに使い込んでないので、後ほど再評価したい
5.Versioned Platform
- Sprong+Javaで統一し、親Pomを各サービスで共有
6.shared interface
- 共通のインターフェースを提供し、コンパイルエラーで気付けるようにする
- 便利だったけどMSAっぽくないと言われる
7.client library
- 6はコンシューマーでインターフェースを実装しなければならず、同じコードがたくさんできて効率悪い
- 実装したクライアントをサービス側で配布。コンシューマー側の実装が楽に。
8.service unit test
- 各マイクロサービスは、Controllerに対してJunitテストを書く（必須）
- 別サービスの呼び出しはモックにする。Mokitoとかつかわず、オーバーライド。
- 複雑な計算等不安な部分は局所的に書く（任意）
- Http通信の部分はSpringbootを利用
- 正常系、異常系のJSONやバリデーションをテスト
9.Service integration test
- サービス結合で期待したデータと違う等のインターフェース齟齬が発生し試験が進まなかった。
- 複数のマイクロサービスを手動で立ち上げてテストする
- 実行をjunitにしておけば残しておける
- 数ケースだけでもかなり問題が検出できる（それくらいインターフェース齟齬が多かった）
10.CI/CD
- AnsibleとJenkinsを利用して環境構築を自動化
- APIのバージョニングをしていなかったので困っている。バージョニングはすごく重要
11.monitoring
- 障害がユーザーからの問い合わせで発覚することが多く監視が必要
- elasticsearchをつかって全サーバーのCPU、メモリ使用率、ディスク使用率やログを採取
- ログは5分間でてないと異常と判断
- 既存メッセージを取り除いて、未知のメッセージが出ているか調べる
- 気づかれなければいいで片付けない。
12.Frontend service & backend service
- 再利用できるバックエンド、再利用しない前提のフロント
13.serverless
14.separated data store
15.イベントソーシング
買い物かごのAPIを、データベース視点のCRUDや追加・削除のようなビジネスロジック的なAPIではなくイベントを登録するAPIだけ提供
- 商品を入れる、出すを全てイベントとして記録する。
データ不整合が発生しても、イベントなら何が原因かがトレースできる
- 処理の追い越しや不正な遷移が発生したときの対応は検討が必要
これからやりたこと
- サーキットブレーカー、リアクティブAPI、コンテナやプラットフォーム
感想とか
手段を目的にしないことが大事
自然と教科書の構成に近づいていく
- 教科書的な構成に合わせなくてもいい
- 自然と似てくる
サービスメッシュとか知らない言葉が増えてたので、常にトレースしていくのが重要
JSUGからのお知らせ
11/24にSpringFest2017
- 会場は両国KFCホール
- 前回と同じく400〜500人の規模を想定
来月の勉強会は10/27。会場は恵比寿のRedhat
JJUG CCC 2016 FALLに行ってきた
秋・・・というツッコミはさておき、2年ぶりにJJUG CCCに行ってきました。 感想は順不同で印象に残ったものから。
懇親会は出たかったけど、風邪がヤバイことになっていたのでパス・・・。
リンク
公式ページ
JJUG CCC 2016 Fallスライドとかのまとめ
GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ
エンジニアの生き方的セッション感想
日本でも出来る！最先端のDevOpsを導入する方法
DevOpsというコール・アンド・レスポンスから始まったセッション。 DevOpsについての非常に熱くそして濃密なセッションでした。
人・プロセス・プロダクトのどれかが欠けてもダメ。
ものすごいオートメーションを実現しても、リリースに誰かの承認が必要という人の面が欠ければ1日10回デプロイは絶対無理。頑張って時間をかけて準備しても、本番にデプロイしたら誰も使ってくれないことだってある。
本番はフィードバックを貰う場所。
未来は予見できないから、フィードバックから学ぶ。マイクロサービスに入社して上司に指示を受けたことがない。ただ「ハッピーか？」と聞かれるだけ。
ハッピーでないのであれば、その問題を一緒に解決してくれる。
上にお伺いを立てないからスピートが上がる。日本は106カ国で一番アジャイル導入が難しい国。
でも、アジャイルの土台にはトヨタ方式や守破離という日本文化がある。
その隙間を埋めているのは西洋文化。
彼らの思考パターンを理解することが重要。日本の生産性が低いのはUSが優秀なわけじゃない。
USは予定されたタスクのうち、大事なことしかやらない。
タスクのうち、無駄なものは計画的に捨てる。 日本は全部やろうとする。
差し迫ったものから、重要かどうかに関わらずをやる。
結果として何もかも中途半端になりやすい。準備に対する考え方。
知らなくてもやってみる。やってから考える。
ソフトウェアの世界で、やってみる前にすべてに備えておくのは難しい。 とりあえずやってみて、やっている間にバリューを見つけ出す。
別に海外がみんなこうだとは思わないし、日本にだってすごいチームはある。
でも、ツールや外側だけを一生懸命取り込もうとしたり、自分たちの組織を変えずにアレンジとかいう体のいい言葉で逃げるのは意味が無い。
考え方を変えないといけないときに来ていると実感。
自分の場合、「とりあえずやってみて、やってる間にバリューを見つける」は欠けてると思う。
色々勉強してきたことからから来る変な思い込みというか見切り。
「やらなくても何となくわかった気になってしまう」というのは悪い癖だと思うので変えていかないと・・・。
JAX-RS REST Client で Cognitive Service や Excel を操作しよう
セッション最初に流れた、ITが目の見えない人をサポートしているビデオ。
ビデオが終わった後、寺田さんが言った「ITサービスが人の役に立つと本当に実感出来るようになった」
これが全てだと思う。
Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか
起こっていることを本当に理解しているか？
どのトレンドをフォローし、スルーすべきか。
午後のDevOpsのセッションと組み合わせて考えるとより素晴らしいかも。
いくら「とりあえずやってみる」でも時間は有限。
全部の技術を試すわけには行かない。
技術的なセッション
詳細はスライドにあるので感想をば・・・。
Selenideを試行錯誤しながら実践するブラウザ自動テスト
WebDriverを使いやすくラップしたフレームワーク。
Codeboneというエストニアの会社が開発。
Jqueryの$ファンクションでエレメントを指定できたり、Ajaxのアサーションを楽に書けたりと、テストが非常に書きやすくなっている。
テスト失敗時に自動でスクリーンショットとHTMLを保存してくれるのはいいと思う。
Payara Micro の設計と実装
Payara Microの仕組みに特化したセッション。 以前、一度試したことがあったのでスムーズに聞けた。
Java EEのマイクロプロファイルがどういう形式になるか分からないけど、Payara MicroはGlassfish使った事ある身としては入りやすい。
Java EE - What's Next?
Java EEの方向性の話。
今までのJava EEがやってきたように、マイクロサービスにおける標準規格を作っていきたい。
「そんなこと実現出来るのかー？」と言うのが今のところの感想。
Java EEと同じやり方であれば、規格に合わせて各ベンダーがミドルウェア出すわけだけど、マイクロサービスまで含めたミドルウェアなんて製品に出来るのか・・・？
クラウドベンダーの依存も何らか発生しそうだし。
あと、Java EE 9の参照実装についてGlassfishってハッキリ言わなかったのも気になる。 それでもマイクロプロファイルは期待。
Kotlin／Go言語デベロッパーミーティング「ライトウェイト言語で行こう！」に行ってきた
大井町きゅりあん大ホール（1000人収容！！）という会場で開催されたイベント行ってきました。
平日午後ということもあり、人はそこそこ。
KotlinとGo言語の本をそれぞれ3000円で買えるという特典付きでした。
値下げした分、無駄なもの省いているのか分厚い本２冊を手渡し。
手提げ紙袋（最悪ビニールでも・・・）が欲しかった・・・。
Androidが生み出す開発言語の多様性
発表資料
概要
Androidの生まれるまでの歴史。
技術的要因で発生していた既得権をオープンにするのがイノベーション。
2010年付近でのWebの進化の速度に比べ、進歩が停滞していたところにAndroidをリリース。
それによって、キャリア等の既得権だったモバイルがオープンになった。
副産物で訴訟問題とか起きたけど。
Android開発者はGoogle好き。
Googleが何かやると喜んで受け入れられる。
レガシーのものでもGoogleが取り上げると受け入れられる。（本当かいな・・・）
感想
JJUGナイトセミナーとかでJava側での事情を聞いたけど、Googleのやり方は仕方なかった面もあるかなと。
JCPでスマホもサポートするJava SE提案しても、通らなさそうだし。
通ったとしてもリリースまで時間もかかりそうだし。(2011年7月のJava7にはきっと間に合わない)
かといって、新しく言語作るほど時間もなし。
Googleのやり方である、先にリリースしてそこから標準にしましょう的なところは現実的だとは思う。
仕様をみんなで決めてからというJCPのやり方は、Googleにすれば遅すぎて我慢できないのかもしれない。
Androidオープンにしたせいで亜種が乱立して統制取れなくなったのは間抜けだけど。。。
JavaからKotlinに乗り換えるはじめの一歩
発表資料
概要
JetBrainがリリースしたKotlinの紹介。
KotlinはJavaの欠点である冗長さやNull問題を解決してくれる。
Javaで何十行も書かなければいけなかったコードが、わずか３行で書けたりもする。
Android対応も公式が強烈にプッシュしているので使えるようになっておいても損はない。
感想
ことりん可愛いよ、ことりん。
Lombokとかで解決されてきているとはいえ、Javaのダメなところを見事に救済している感じ。
KotlinからJavaの呼び出しも可能なので、過去の資産やJavaの便利なライブラリを使うことも可能。
逆にJavaからKotlinの呼出しはハマリポイントが多いらしいので、フレームワークから使うのはコツがいるかも。
気になったのはJava6のバイトコードが生成されるということ。
Android向けだからだと思うけど、Indyとか使えたらもう少し効率あがりそうなので残念。
あ、ビルド含めるとKotlin・Java・Groovyと３つの言語が必要っていうのはなんか面白い。
Java Day Tokyo2016の不満点まとめ
ちょっと書かざるをえない
運営的なもの
- 会場が色々な意味で狭い
- 展示をもう少し充実させて欲しい
- スポンサーや企業のデモを見るのも楽しいのに。。。
- Dukeくんと記念撮影もなかったし
そのくせ物販だけは例年通りやってるし
- 寒かった
- セッション資料の公開はアナウンスして欲しい
- スライド切り替わる度にシャッター音がウザい！！
- 机がないのはまぁいいとしても椅子が辛い・・・。
- ２時間で終わるナイトセミナーとかならともかく、1日座って聴くのには辛い
- 品川プリンスの椅子は良かったw
- ストリーミングが気がついたら終わってた？
- 終わったならアナウンスだそうよー
まぁ、一昨年去年に比べて、予算を大幅に削られてるなぁとは思いました。
スタッフも少なめな気もしました。
来年もちょっと不安・・・。
良かった点
- セッション入場前にバーコード読み取りなくなったので、スムーズに入れて良かったかも
- その代わり予約が全く機能してなかった気もする
- 単純に参加者ごとにカード作る手間にお金を使えなかっただけかもしれないけど:P
JAVAのおじさん
業務サボるために来てるとしか思えないオジさんはどうにかできないものかね。。。
- セッション中寝てる
- 専門的な話は難しい、仕方ないよね
- セッション中にツムツムしてる
- お仕事の話よりゲームのほうが面白い、仕方ないね
Java Day Tokyo2016に行ってきたよ
都合のため、キーノートとナイトセッションは参加できず。
午後の５セッションの感想です。
スライドがアップされたら更新するかも
Introduction to MVC 1.0
Java EE 8に含まれるMVC1.0の概要の説明。
深く突っ込んだ内容はなし。
「MVCとは？」の説明からなので、基本的なところから学べた。
そうは言いつつも、さりげなくViewでFreeMaker使ってるサンプルがスライドに入ってたり。
実装はOzark。
仕様はそれほど難しくなく、JAX-RSを使いこなせてる人ならそのまま使えそうな感じ。
SpringMVC慣れてる人も大丈夫そう。
感想としては、Viewの指定方法が沢山あるのは使う時に迷いそうなのが微妙。
まとめにもあったけど、Java EEにMVCという選択肢が増えるのは良いことであるのは間違いない。
ただ・・・遅すぎない？
EE７に入っていればよかったのに・・・。
Java EE 7 アプリケーションとWebセキュリティ
スーツ姿の裏紙さんセッション。
IPAが公開している、安全なWebサイトの作り方をJava EEでどう実現するかの話。
重要なこと
- 最初からセキュアなコードを書くこと。セキュアじゃないコードをセキュアにするのはコストが高い
- 対策も必要だけど、脆弱なコードをチェックする仕組みも必要
- それぞれの対策は簡単だけど、攻撃がどういう仕組みでどういう理由で対策できるのかを知らないと対策しても不安が残る
- セキュリティに関する資料は一般的に多く出回っているので、普段から勉強しておくのが大事
- ビジネスロジック（モデル）で対応するのは、可読性や保守性に悪影響。なるべくViewやControllerで対応する
各攻撃に対する対策
JSPや低レベルな処理の話もあったけど、面倒なので割愛。JSFを使おう。
XSS
Faceletならデフォルトで対策済。
CSRF
JSFなら対策不要。
ただしViewをステートレスにすると対策が必要になる。
ステートレスとステートフルを使い分けるといい。
SQLインジェクション
JPAの@NamedQueryアノテーションを使う。
em.createQueryはクエリ文字列を受け取るため、SQLインジェクションの脆弱性があるクエリを指定される可能性がある。
CriteriaAPIを使う手もあるが、学習コストが高いのでオススメはしない。
パスのパラメーターチェック
JavaのFileAPIをそのまま使うのではなく、パラメータチェックを行うラップAPIを作成して利用する。
こうすることで、FileAPIで検索して脆弱なところを検出できる。
クリックジャッキング
レスポンスヘッダーに、X-Frame-Optionsをつけることでiframe、frameを禁止できる。
ただし、Ajaxで行うファイルアップロードも潰してしまう可能性があるので、すべて禁止するのではなくSameOrigin指定を推奨する。
OSコマンドインジェクション、バッファーオーバーフロー
割愛。
どちらも普通に作っていれば起こらない。
その他
レスポンスヘッダーに以下の二つをつけるといい。
X-Content-Type-Options:nosniff
IEはコンテントタイプが指定されていないものを自動で判断する。
そのため、悪意のあるコンテンツを解析した際にスクリプトを実行される可能性がある。
このヘッダーをつければ自動解析を無効にできる。Content-Sequrity-Policy 最強のCSRF対策だけど、CSSやイメージを妨げる可能性あり。
すべて禁止ではなく、許容するリソースを指定する。
Java Concurrency A(nother) Peek the Hood
Javaの並行処理に関する話。
わかりやすかったけど、技術的にはかなり深い所。
概要
- Webアプリケーション、GUIはマルチスレッドが普通
- ライブラリを公開する場合も、マルチスレッドで使われることを考慮しよう
というより、シングルスレッドが許されるのは学校の宿題まで
ConcurrentAPIとか使い方を暗記していても仕組みを理解してないのは危険
メモリモデルを正しく理解しよう
マルチスレッドの場合、各スレッドによって実行順の基準が異なる
Javaの場合はHappened-before
Java SE 5まではfinalがイミュータブルではなかった
並列処理ライブラリを利用するときは、なるべく抽象化されているものを使う。具体的な処理を利用すると実行効率が良さそうに思えるが、とても難しく問題も出やすい。
本番と同じ環境でテストすることが大事
本を読むならJava Concurrency in Practiceがおすすめ
実践してわかったJavaマイクロサービス開発
モノリシックなWebアプリケーションをマイクロサービスに変えていった経験の話。
マイクロサービスは技術的な話は多いけど、実践例は少なかったので参考になった。
スライドが丁寧だったので、内容の詳細は省略。
参考になった点
- サービスディスカバリーは必須
- クライアントとサービスを共通のインターフェースにすることで、IF仕様書を作らなくて良くなる
- 多言語化はEurekaとの関係もあり難しい
- サーキットブレーカーは障害が起きたらどうすればいいかまだわからない
- HTTPは同期処理。AMQPは戻り値なしの非同期
- 画面を中心にAPIを考えると、巨大なものになりやすい
- ドメイン分割は大事。ドメインごとにサービスを作るくらいがちょうどいい
Javaエンジニアのためのクラウド時代の過ごし方
これもスライドがとてもいい感じなのでポイントだけ。
決してお酒が回って面倒なわけではない。
考えさせられた点
- 今までは作ることが大変だった。しかし今は作るところは簡単になり、運用面の問題に向かい合えるようになった。
- 良いコードを書くことは大事だけどそれだけじゃダメ
- アジャイル、クラウド、DevOPS、マイクロサービスは、それぞれの組織が取り組んできた結果
- クラウドによって、ハードウェアがソフトウェアとして定義できる
- 自動化、コピーができる
- 非機能要件のテストが書ける
- PaaSは稼働しているミドルウェアを借りるイメージ
- インフラのテストは本番環境でしかできない。そのテストをするのがNetflixのカオスモンキー
- カオスモンキーはランダムにサービスをダウンさせる
- カオスゴリラはAZを丸ごとダウンさせる
- カオスキングコングはリージョン丸ごとダウン
- ダウンの目的は自動で復旧するかの確認。手順書ではなくコード。運用を不要にする。
これからのエンジニア
２つのどちらかにならないといけない
JSUG勉強会 2016年その3.5に行ってきました
イベントページはこちら
JSUG勉強会 2016年その3.5 - Kenny Bastani来日特別講演 - 日本Springユーザ会 | Doorkeeper
SpringBootを中心とした、マイクロサービスについてのセッション。
テーマ自体が難しいことに加えて、QAを含めて通訳なし100%英語というハードコアなセッションでしたが、ためになるお話でした。
最大の敵は開始前のピザとビール・・
セッション概要
開始前の会場アンケート。 SpringBoot使ってる人はたくさん挙手があった。
逆にSpringCloudを使ってる人はほぼいなかった。Apache、Tomcat、MySQLで構成されるモノリシックなアプリケーションから、SOAを経てマイクロサービスになる。
マイクロサービスは、各サービスで共有するShered Cacheとそれぞれのサービスの特性に応じたDBMS等のリソース。
サービスごとにリソースを分けることで、1つのサービスがダウンしても全体はダウンしない。インフラストラクチャもスケールアウトが難しいモノリスな構成から、スケールアウトが容易なコンテナへ。
マイクロサービスはコンテナ単位で依存関係を持つ。 依存関係の解決はServiceDiscoveryがおこなう。SpringBootのMavenダウンロード数は、2015年12月に225万を突破
SpringBootは「フレームワークのためのフレームワーク」
SpringFrameworkがケーキの材料だとしたら、SpringBootは完成したケーキ。 ケーキを作成するキッチンがSpringInitializr。 SpringBootがケーキだとしたら、SpringCloudはケーキが並んだショーケース。
デモ
マイクロサービスで構築したショッピングサイト。
ソースは↓。
何がすごいって、モノリシックな普通のWebアプリケーションにしか見えないくらいサクサク動く
しかも動いているだけじゃなく、メトリクスもキチンと取っている。
「WebAPIを使いまくると遅い」と決めつけるのは間違いだった。ソースはまだあまり見てないけど、サービスの単位は思っていたよりも小さい
ただ、メモリは全体で8.5GBくらい使っているっぽい
モノリシックに比べれば、大きくなりそう
Q＆A
QAもほとんど英語。
あまり聞き取れなかった。。。
質問の傾向としては、マイクロサービス構築時のベストプラクティスやガイドラインについて聞いているのが印象に残った。
回答としては、ケース・バイ・ケースと言った感じ？
反省点
やっぱり終わる前にお酒を飲んではいけない。
後半はマッタリしてしまった・・・。英語で質問出来るようにならないとまずいなぁ・・・。
他の人の質問を聞いてて思ったことは、最初に質問内容をバーンと言ってから、細かい事情や背景を説明したほうが良さそう。
詳細を先に話し始めると、説明が難しくてそこで詰まってしまう。
聞いてる方もどこから質問なのか判別が難しくなりそう。今年度(not 今年）は勉強会に行ったらブログを書く。
いじょ！
データのマスキングが気になったので調べてみた
セキュリティの要件を検討中、データのマスキングについて気になったので調べてみた。
具体的なシチュエーションとしてはこんな感じ。
- システム導入先のユーザーと、そのシステムを構築・保守するSIer
- SIerはテストや障害調査等でユーザーの個人情報含むデータ（顧客テーブルとか）が必要
- 従来通りの氏名とか住所をマスキングすることは、個人情報保護法的にOKなのか
法律の解釈についてはあまり詳しくないので、間違っている箇所もあるかもしれないのでご容赦を。
匿名加工情報
個人情報保護法には「匿名加工情報」という言葉の定義があり、以下のように説明されていた。
・特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものをいう。
・当該個人情報に含まれる記述等の一部を削除すること（当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。）。
・当該個人情報に含まれる個人識別符号の全部を削除すること（当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。）。
「個人識別符号」も定義されている。
・特定の個人の身体の一部の特徴を電子計算機の用に供するために変換した文字、番号、記号その他の符号であって、当該特定の個人を識別することができるもの
・個人に提供される役務の利用若しくは個人に販売される商品の購入に関し割り当てられ、又は個人に発行されるカードその他の書類に記載され、若しくは電磁的方式により記録された文字、番号、記号その他の符号であって、その利用者若しくは購入者又は発行を受ける者ごとに異なるものとなるように割り当てられ、又は記載され、若しくは記録されることにより、特定の利用者若しくは購入者又は発行を受ける者を識別することができるもの
特定の個人の身体の一部の特徴の例としては、顔写真とかが考えられる。
病院のカルテとかなら、病状や治療歴も含まれそう。
2つ目はクレジットカードや銀行口座の番号が該当する。
伝票番号とかは、他のデータと突き合わせれば購入した人がわかる可能性があるけど、この文には「他の情報と照合」という言葉が入っていないので許されるかもしれない。
ここまでのまとめ
- マスキングして個人を特定できなくなったデータは個人情報保護法における「匿名加工情報」になる
- 氏名や顔写真等は当然として、IDも削除しないといけない対象になる可能性がある
ID系についてはこんな感じ。
匿名加工情報の作成
これも法律に書いてあった。
・個人情報取扱事業者は、匿名加工情報（匿名加工情報データベース等を構成するものに限る。以下同じ。）を作成するときは、特定の個人を識別すること及びその作成に用いる個人情報を復元することができないようにするために必要なものとして個人情報保護委員会規則で定める基準に従い、当該個人情報を加工しなければならない。
・個人情報取扱事業者は、匿名加工情報を作成したときは、その作成に用いた個人情報から削除した記述等及び個人識別符号並びに前項の規定により行った加工の方法に関する情報の漏えいを防止するために必要なものとして個人情報保護委員会規則で定める基準に従い、これらの情報の安全管理のための措置を講じなければならない。
・個人情報取扱事業者は、匿名加工情報を作成して当該匿名加工情報を第三者に提供するときは、個人情報保護委員会規則で定めるところにより、あらかじめ、第三者に提供される匿名加工情報に含まれる個人に関する情報の項目及びその提供の方法について公表するとともに、当該第三者に対して、当該提供に係る情報が匿名加工情報である旨を明示しなければならない。
・個人情報取扱事業者は、匿名加工情報を作成したときは、個人情報保護委員会規則で定めるところにより、当該匿名加工情報に含まれる個人に関する情報の項目を公表しなければならない。 ・個人情報取扱事業者は、匿名加工情報を作成して自ら当該匿名加工情報を取り扱うに当たっては、当該匿名加工情報の作成に用いられた個人情報に係る本人を識別するために、当該匿名加工情報を他の情報と照合してはならない。
・個人情報取扱事業者は、匿名加工情報を作成したときは、当該匿名加工情報の安全管理のために必要かつ適切な措置、当該匿名加工情報の作成その他の取扱いに関する苦情の処理その他の当該匿名加工情報の適正な取扱いを確保するために必要な措置を自ら講じ、かつ、当該措置の内容を公表するよう努めなければならない。
公表・・・？
えー、まとめると・・・
- データをマスキングする時は、個人情報保護委員会規則で定める基準も考慮しないといけない
- 加工の方法はバラしちゃだめ
- 第三者に提供するときは公表しないといけない（！？）
『みなさんこんにちわ、○○商社です。今回、わが社の顧客情報管理システムでトラブルが発生しました。つきましてはお客様のデータのうち氏名、住所を秘密にした顧客情報を、委託している××システムに提供します』とかプレスリリースとかに乗せろということ・・・なのか？ - そもそも匿名加工情報を作った自体、公表しないといけない（！？）
なんかすごく面倒・・・。
少なくともシステムを開発・運用するSIerとの関係だと、法律通りの運用はされないのでは・・・。
